ZH version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
85% Positive
Analyzed from 1094 words in the discussion.
Trending Topics
#database#why#things#don#article#doesn#those#actually#foundationdb#compare
Discussion (27 Comments)Read Original on HackerNews
To me it reads a bit like, how we built our office without desks: it turns out if you stack two chairs on top of each other, you can balance your laptop on the top and you’ll also have a shelf on the bottom for your things.
But that sounds kinda unstable and doesn't really provide the full benefits we expect from a...
Oh.
For those working with databases, it's easy to come up with a bunch of reasons. ORM is a necessary evil when working with RDBMS, as are things like schema migrations that can easily result in loss of data (I.e., dropping columns or tables).
What if all we need is dumping a big old JSON in a container?
This idea is very enticing. The scale of this whole NoSQL thing is pretty telling.
The blog presents a thought provoking question: what if we don't actually need a full-blown database, and instead we only care about things like unique constraints, transactions, indices, and history tables.
What if we only need a subset of those?
Hmm, neither of those been necessary for me. ORMs is a choice, you can choose not to and still have a proper design and architecture and not suffer from that choice. Requires you have programmers who know how to use SQL, which seems less and less common as the days go by though, so understandable most reach for an ORM.
Schema migrations that can "easily result" in data loss is even easier to avoid though. Don't drop the column/table in the same step you copy data to the new place, or do the migration via application code which gets cleaned up later, to catch most of the stuff before one bigger copy, and then the eventually DB cleanup.
Guess it depends on how careful you want to be, or how careful your agent lets you be, I guess. But it's definitely possible to avoid both of those "necessary evil", which I guess makes them just "evil".
That might be a very specific assumption. What about serializability? Replication? Materialized views? Procedures? Locking? Access control?
It’s cool to experiment and try new approaches. Neat one here.
Could still end up moving to Postgres.
Your time and attention is precious as a developer. I'm absolutely sure it's possible to implement uniqueness constraints, transactions, indices, and history yourself, but is that really the most valuable use of your time? There's probably not a need for you to have a unique solution, so you're quite literally just re-inventing something someone already had for not a lot of benefit.
Wouldn't your time be better spent actually solving the problems that whatever you're building is supposed to solve?
What if you just ran FoundationDB instead?
Would that let you do collaboration blog-posts with another VC-funded startup though?
Also, the database is the last thing you want to re-invent unless your business is explicitly building a db (even then it's best to re-use a db like all the postgresql forks that have existed)
good news, FoundationDB is already invented, and just slightly more tested than others on the market.
Did it take 10 seconds of prompting? Or hours of thought, trial error and revision? Especially when asking people to read for 20+ minutes...
If you only have binary encoded protos to worry about (which is typical) then you can rename fields.
For about a decade, I've been using flat files on disk or object storage for most of my side projects. There's even a python library that handles some of the plumbing for you [1].
If you don't have strong record-level concurrency needs then it's a lot nicer, easier, cheaper than a relational or document database. And if you do need that, you can design your data model around what defines a record.
[1] https://tinydb.readthedocs.io/en/latest/
I generally don't read low-quality AI slop though, so its possible I missed an explanation that didn't contain those key words.
Article flagged as AI slop.
Two things the post doesn't cover and I'm happy to get into. What closing the cross-region lost update actually took: annotating the RPCs that depend on a compare-and-swap and replaying those to a single region, with a client-side guard. And the read amplification, which we have a plan for but waiting on a clear signal for when it’s needed.
Cross-posted with thanks to the Tigris folks; the original is at ampbase.io.
Set of my Claude alarm bell, and lo-and-behold, Pangram judges this comment to be 100% AI-generated, albeit with limited confidence.
This is Claude between the lines admitting none of it was needed. Postgres on a VM would be doing just fine right now.
edit. Clearly the joke about "lo-and-behold" didn't land well with the bots...
https://en.wikipedia.org/wiki/Compare-and-swap
CMPXCHG
https://www.felixcloutier.com/x86/cmpxchg
https://lwn.net/Articles/847973/
From the article:
> In practice, when you reach for a database engine you're actually reaching for four basic features: unique constraints, transactions, indices, and history tables. In order to use Tigris' global object storage as a database, we had to implement all of these primitives ourselves.
Not sure why the "without a database" is or isn't so important, why is it mentioned so often and why the article flip-flopping between "we don't have a DB" and "we're effectively building our own DB"?