adam_oxla

Amazing overview. Right now I work on a completely new OLAP database: vectorized query execution is must have nowadays if you want to have competitive performance. What's interesting is that vectorized query engines benefits a lot from SIMD instructions (that is obvious). But what is less obvious is that rising popularity of ARM CPUs made it more complex to developer vectorized query engine because one has to provide support for both architectures.

I was working in Google in years 2013-2016. It was amazing experience at that time. In no other place I have learned so much on how to run large organizations efficiently: before I was working in several companies having tens employees and 3 companies having hundreds of employees.

While Google could not compete with companies with tens of employees it was more efficient than companies having hundreds of them that I worked in.

Nevertheless something bad was already starting to happen: already at that time some employees working at Google for many years liked saying that new Google is like old Microsoft and new Microsoft is like an old Google.

I think that at some point Google stopped having an idea on how to grow their business using new product so they started growing revenue by other means: changing a product pricing model or cutting the cost.

I think that at some point company growth will converge to, more or less, GDP of market at which company is operating. This might be something hard to accept for the company that was growing so fast for so long.

While I do agree that for most of companies those large SaaS solutions are overkill I do not think that DuckDB or similar is sufficient. Nowadays more of the companies really need to process large datasets.

I meet regularly companies that used PostgreSQL or something similar up to some point but then they have grown and it is not sufficient anymore. They need something scalable. It does not have to be large SaaS: in many cases small Clickhouse cluster is sufficient. Nevertheless not everything can be done using single server. Also even if customer knows exactly well what are their needs right now does needs will grow and change over time so it is reasonable to build something that is not only good enough for now. Of course building something absolutely "future proof" leads to extremes and high bills.

It is surprising how popular is using O(N^2) algorithms that are simple in implementation even in extremely popular libraries. E. g. ICU search method: https://github.com/unicode-org/icu/blob/a7a2fdbcf257fa22c7a2... ICU is used by Python, Windows or OpenOffice.

Great article. I was recently wondering why are vector databases useful at all. There are cases (LLMs) where they are useful. But apart from that, most of the cases I have encountered, requires indexing on different data types than vector. I might be biased due to my experience but in a very typical use cases e.g. analyzing event streams or building recommendation engine you want to filter rows by timestamp and client id or product category and availability. Vector index is not that useful in those cases.

That's why I think that outside some very specific use cases vector databases are not very useful.

Amazing article. I have not seen such a comprehensive guide yet. Although when I have seen the title I was expecting it would be focused more on CPU inner workings: superscalar pipelines, frontend, backend, instruction fusing, memory banks, instruction cache, branch prediction, instruction reordering etc.