PostgreSQL is enough • Hacker News Board

Re: PostgreSQL is enough

#321

Post by dgsb » Wed, Feb 14, 2024, 10:27 AM UTC

bun_terminator wrote: post #87

As a hardcore c++ guy, I recently switched to a company heavily into databases. I never had contact to databases before. And I'd like to go one step further: Why databases? I come from an industry that heavily uses custom binary file formats. And I'm still bewildered by the world of databases. They seem to solve many issues on the surface, but not really in pratice. The heavy limitations on data types, the update dis…

For custom binary file you could and should use sqlite, it has many benefits instead of writing your own custom file format. You just have acid without any cost. It's a single file database you can access throuhg lib statically linked in your application and that's done.

You can check these links:

https://sqlite.org/appfileformat.html

https://sqlite.org/aff_short.html

Re: PostgreSQL is enough

#322

Post by dgsb » Wed, Feb 14, 2024, 10:43 AM UTC

bun_terminator wrote: post #245

ndriscoll wrote: post #242

Earlier quoted context omitted.

If you're going to find yourself working with databases, I'd suggest learning some about the internals (that's probably true of anything). In particular Markus Winand's information[0] is great for building an intuition about why different types of queries work with different types of indices. I don't know about Oracle, but Postgres and Mysql have pretty detailed documentation once you have that foundational knowledge…

I don't plan on staying long enough so that a deep investment is useful. I'd rather continue my efforts into getting rid of some database stuff. I certainly won't work with databases ever again after this, so every hour I spend with it is wasted. I'll pass on this technology. But I appreciate the effort.

You should seriously check sqlite3, it will save many engineering hours. free acid and btree.

Re: PostgreSQL is enough

#323

Post by dgsb » Wed, Feb 14, 2024, 10:44 AM UTC

hobs wrote: post #137

bun_terminator wrote: post #125

Earlier quoted context omitted.

But that's the thing: All that is nice on paper. Of course the relational nature is nice. Of course the disk representation is nice. But I never feel like that's worth the trouble day in day out. The costs, the mystery box of performance, the insane statements, the extra hardware, the updates, the strange data types, the box of tricks everyone needs to make them behave. But I've been made aware that our usecases suck…

The problems are not specific to SQL though - if you want to store and manage huge amounts of data you're going to need some specialized data structures, some way to manage disks paging and memory, manage consistency, isolation, durability, and atomicity of your changes. The general idea is that its such a PITA to deal with all that so just let a database do it, and of course the consequence is an often leaky abstrac…

It's more than a PITA, it's almost impossible to implement ACID correctly. It's very very hard to do. There almost no point in implementing that in house when we have sqlite3.