> A commercial version of PostgreSQL server that has row-level security and natively replicates with SQLIte over HTTP(S). Easy offline mobile apps.

This, if done well, could be awesome. How you would effectively guarantee row-level security?

One thing that I've been thinking about a lot is a database whose rows are only readable by the users that generated the data in those rows. Essentially, the data in each row is encrypted with a key that's generated from the password of the user.

Data breaches are bad because, among other reasons, nothing in the database is encrypted. If each row was encrypted with a key only recoverable from a user's password it would solve a lot of problems.

Some RLS updates coming in 9.4 . Updatable security_barrier views, as well as updatable WITH CHECK OPTION views. Can be done now sorta, but is a PITA.

Generally speaking, encryption isn't the answer. Hard to search, hard to sort, hard to index.

RLS using views works well, but has some issues such as Covert Channels. See http://wiki.postgresql.org/wiki/Row-security .

Don't think it would be a problem regarding replication, as long as remote databases can't query as they please.

How would you combine that with indexing? Seems like data needs to be unencrypted to be indexed. And if you're not doing any indexing, isn't it as simple as converting the user's data to JSON, and encrypting the JSON?

Aye, there's the rub. Lots of nice features disappear when you're only storing encrypted data. I suspect that it's not possible to create an index of the data (before encrypting it) that doesn't leak information and thus ruin the encryption (but IANACryptologist).

It would really only be useful for data you're not joining on or searching over, and then you've got more of a dumb data store than a database.

It might be useful if a database could enable encryption on specific columns (which would make those columns unindexable).