4 ms·
Hi All, I've been working on this project on-and-off for a few years now, and thought it was time to show it to the public. The Gist: BedquiltDB is a vaguely
by s_kilk 11y ago
Hi All,
I've been working on this project on-and-off for a few years now, and thought it was time to show it to the public.
The Gist:
BedquiltDB is a vaguely mongodb-inspired json store built on top of PostgreSQL's jsonb column type. It does the things you'de expect, creating _id fields automatically, creating tables on the first write, etc.
It is implemented as a postgres extension (a horrible lump of PL/PgSQL), and client libraries for python, node and clojure.
While I'm not using it in production for anything, it is pretty well tested, and I had fun making it, which is what really matters :)
Questions welcome!
- e12e 11y agoAny particular reason to choose PL/PgSQL over other extension languages?
- s_kilk 11y agoIt seemed to be the most performant option available, aside from C. I wouldn't be opposed to re-writing in a more-performant extension language if needed. EDIT: also, PL/PgSQL is installed by default, and I wanted to see if I could get this project to work without any other dependencies aside from a base PostgerSQL 9.4 installation.
- Dowwie 11y agoYes, it makes sense to write it in whatever was most performant
- metalliqaz 11y agoNot requiring any external dependencies is a huge plus in my book.
- alfanick 11y agoEspecially when PL/V8 seems natural when working on JSON(b). It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately).
- s_kilk 11y ago> It even is much faster compared to PL/pgSQL (at least in a project I've been working on lately) That's good to hear. At the time I had read somewhere that PL/V8 can be slow because it needs to cast/convert data back and forth between javascript and native Postgres representations. It's possible that that assessment is wrong, however.
- alfanick 11y agoOfc make your own benchmarks before taking PLV8 into consideration. In my case PL/pgSQL FOR loop was particularly slow; lack of builtin data structures like map or stack (though stack is emulated in V8 via array) caused performance problems – array operations are really slow in PL/pgSQL (compared to V8), instead of using map I've use indexed temporary table (creation of such is quite costly). Still you might have a point here – PL/pgSQL stores execution plans with the function, so there is a chance of being more efficient here.
- baudehlo 11y agoDid you try using plain SQL with unnest()?
- jerrysievert 11y agoPL/V8 maintainer here - yes, JSON/JSONB structures are brought through the C++/Javascript membrane, but for the most part it doesn't seem too slow (full disclosure, i wrote a mongo clone on PL/V8 a few years ago). but, there is also the ability to simply query from inside a function using plv8.execute(), which gives you the ability to use JSONB operators, which are much faster.
- fiatjaf 11y agoYears? But JSONB hasn't been alive for such a long time.
- davyjones 11y agoMaybe they started with hstore and replaced that over time.