HN user
software engineer based in nyc
The spirit of this is correct, but a better approach to this is going for a walk with just your thoughts.
Yes, that means no phone, no headphones, just you and your brain enjoying a walk. Let your mind wonder and be free.
The underlying C library interacts directly with the postgres query parser (therefore, Postgres source). So unless you rewrite postgres in Rust, you wouldn't be able to do that.
grug very elated find big brain developer Bob Nystrom redeem the big brain tribe and write excellent book on recursive descent: Crafting Interpreters
book available online free, but grug highly recommend all interested grugs purchase book on general principle, provide much big brain advice and grug love book very much except visitor pattern (trap!)
Grug says bad.
In all seriousness, the rough argument is that it's a "big brain" way of thinking. It sounds great on paper, but is often times not the easiest machinery to have to manage when there are simpler options (e.g. just add a method).
https://duckdb.org/docs/stable/core_extensions/vss
It's not bad if you need something quick. I haven't had a large need of ANN in duckdb since it's doing more analytical/exploratory needs, but it's definitely there if you need it.
Just curious what the state of the art around filtered vector search results is? I took a quick look at the SPFresh paper and didn't see it specifically address filtering.
In any API service, it's better to handle via dependency injection IMO.
Instantiate all of your metadata once, and then send that logger down, so that anybody who uses that logger is guaranteed to have the right metadata... the time to add logging is not when you are debugging.
Might be missing my argument here - I stated that there are workable solutions to this like you have pointed out.
But ANN search is still a sledgehammer and building out hybrid solutions that help bridge the gap between this and traditional data stores still have room for innovation.
Sure they can handle the basic case of ANN. But ANN still doesn’t have good stories for lots of real-world problems.
* filterable ANN, decomposes into prefiltering or postfiltering.
* dynamic updates and versioning is still very difficult
* slow building of graph indexes
* adding other signals into the search, such as query time boosting for recent docs.
I don’t disagree these systems can work but innovation is still necessary. We are not in a “data stores are solved” world.
I don't disagree that rock solid is a good choice, but there is a ton of innovation necessary for data stores.
Especially in the context of embedding search, which this article is also trying to do. We need database that can efficiently store/query high-dimensional embeddings, and handle the nuance of real-world applications as well such as filtered-ANN. There is a ton of innovation in this space and it's crucial to powering the next generation architectures of just about every company out there. At this point, data-stores are becoming a bottleneck for serving embedding search and I cannot understate that advancements in this are extremely important for enabling these solutions. This is why there is an explosion of vector-databases right now.
This article is a great example of where the actual data-providers are not providing the solutions companies need right now, and there is so much room for improvement in this space.
The README is 100% just autogenerated by Claude. It looks like every README generated from these tools.
Can’t speak for the code since I haven’t peaked into it
While not strictly for RDBMS, I think this book is pretty close!
Just wanted to say thank you for this article - I've read and shared this a few times over the years!
When Breath Becomes Air by Paul Kalanthi.
A fascinating memoir by a philosopher turned brain surgeon, facing a terminal cancer diagnosis. A person who spent their entire life pondering the morality of life being faced with their own ultimatum.
I reread it once a year, at minimum. A deeply moving book.
My system’s programming teacher spent an entire week of a 12 week semester (3 classes) going over how to use gdb/vim for one of our projects.
Still my favorite class and professor from my time at school.
Can anybody speak to how Vespa compares to some other Vector Database solutions? Seems like there's so many options today
Could also make a guess that the blackout has changed how their normal traffic patterns operate, causing some issues with autoscaling/hot partitions.
I like this viewpoint when you are a small company searching for PMF and your entire backend can fit into a small DB.
At one point you'll have to reckon with IO costs and storage once that is over and then you have no choice but to exploit data locality more heavily.
Just saying, YMMV depending on how much data is in your database.
As somebody that has done both contracting and worked in tech, I hope this comment makes sense.
Most homeowners (product managers) want the cheapest (fastest) thing that fixes (delivers) a working home (feature) to them. When given the options those are generally what people choose.
Sure some contractors (software engineers) always cut corners, but I believe many take pride in their work and given the option would prefer a solution they take pride in.
I trust you have the numbers for this. And we can debate them until the world ends, but I think having a mental fallback that “yeah, some people suck” is valuable for your mental well being.
Life’s too short to let the few negative people out there bring you down. 1% or 5% whatever lets you realize that and move on
I find it more efficient to work in topic-scoped batches, so I can load context on a protocol and codebase once and use it to land multiple changes.
This is my favorite way of writing software as well. My current gig has a ton of microservices, and when a feature comes up that requires changing one of them, I much prefer to make a couple other, smaller changes that help keep the service operational and easier to maintain with it.
One issue is that this often times bring out the yak-shaving, but I think it's a fair tradeoff and helps reduce the time burden of doing large migrations.
Lays off 20% of employees and the stock jumps 9% immediately. Really drives home a good message to all CEO's out there /s
It would always be nonsensical unless you were running on the database you were targeting (or one that contained similar data distributions).
However, with Postgres its pretty trivial to get a JSON format of the output if you needed a machine parseable answer. I don't know of a library that does this for you, but it wouldn't surprise me if one existed.
explain (format json, analyze, buffers) select 1The feature requests (asks) that product wants to build - sorry for the confusion there.
No disagreement here. I love a good monolith.
Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database.
Use One Big Database.
Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care).
It is so much easier to do these joins efficiently in a single database than fanning out RPC calls to multiple different databases, not to mention dealing with inconsistencies, lack of atomicity, etc. etc. Spin up a specific reader of that database if there needs to be OLAP queries, or use a message bus. But keep your OLTP data within one database for as long as possible.
You can break apart a stateless microservice, but there are few things as stagnant in the world of software than data. It will keep you nimble for new product features. The boxes that they offer on cloud vendors today for managed databases are giant!
Came here to comment this, there's a ton of awesome stuff around Postgres that using RDS makes impossible. Kinda stinks, but I don't have the time/expertise to manage a Postgres Instance on EC2.
Previous Discussions:
High Scalability has some good articles around this.
Building a dashboard by clickety/clacking around is not a menial task, consistency across dashboards is a a core unit of observability to ensure x-functional teams can discuss issues across a common language/viewpoint, which is only enforceable through a declarative dashboard syntax.
Grafana alerts (before version 8) worked great. We use them, but the Grafana 8 alerting features are half-baked at best.
* Grafana 8 alerts removed the Image Preview, which was extremely useful during issues. [0]
* Grafana 8 alerts don't have any way of being stored as code. In fact the API that they provide in their docs [0][1] doesn't work, or isn't up to date.
* The expression languages have zero documentation about them, so aren't exactly useful for things that might get a developer out of bed in the middle of the night.
[0] https://github.com/grafana/grafana/discussions/38030#discuss...
[1] https://editor.swagger.io/?url=https://raw.githubusercontent...
[2] https://community.grafana.com/t/posting-an-alert-using-grafa...