5 ms·
This post illustrates the difference between persistence and a database. If you are expecting to simply persist one instance of one application's state across
by jeff-davis 6y ago
This post illustrates the difference between persistence and a database.
If you are expecting to simply persist one instance of one application's state across different runs and failures, a database can be frustrating.
But if you want to manage your data across different versions of an app, different apps accessing the same data, or concurrent access, then a database will save you a lot of headaches.
The trick is knowing which one you want. Persistence is tempting, so a lot of people fool themselves into going that direction, and it can be pretty painful.
I like to say that rollback is the killer feature of SQL. A single request fails (e.g. unique violation), and the overall app keeps going, handling other requests. You application code can be pretty bad, and you can still have a good service. That's why PHP was awesome despite being bad -- SQL made it good (except for all the security pitfalls of PHP, which the DB couldn't help with).
- mrkstu 6y agoMaybe also part of the success of Rails? Similarly an easy to engineer veneer atop a database.
- perlgeek 6y agoI'd say the universal query capability is the killer feature of SQL. In the OP they spent two weeks designing and implementing transaction-save indexes -- something that all major SQL RDBMS (and even many NoSQL solutions) have out of the box.
- psankar 6y agoThis comment helped me understand the problem and the solution better (along with a few followup tweets by the tailscale engineers). Thanks.