[jstimpfle]

For mildly interesting code that you can realistically write yourself, there isn't a strict need to share code and cross polinate. Every little shop has a certain budget to try out new things, play around, and learn. If we come up with more or less the same things, that's fine.

I'm much more fond of sharing ideas than sharing code. IMO developers' understanding is at least as important as the economics of crafting code.

Of course you can't rewrite Postgres for your CRUD project. It's fine to use third party projects but there might be less need than one would assume. A lot of projects don't need a full-blown database, and I'd find it great if there was more practical reasearch how to design minimal storage systems for example. I'd bet that the majority of all apps that depend on Postgres would easily fit in RAM, forever. That could mean one could get rid of SQL, or could apply other simplifications.

[paulryanrogers]

> I'd bet that the majority of all apps that depend on Postgres would easily fit in RAM, forever. That could mean one could get rid of SQL, or could apply other simplifications.

My guess is you're correct, yet RAM stored DBs cannot guarantee persistence when things go wrong. Or at least they may introduce data loss if changes aren't fsync'd to durable storage or 2PC with replicas.

[jstimpfle]

It already simplifies some things if data is available directly from RAM. And many stores are read-only or read-mostly.