Benchmarks

[alexgleason]

I would love to see how this compares to SQLite in WAL mode, and if running Postgres in a single thread will actually beat it.

[vitonsky]

I completely agree here. Your solution looks interesting, but as developer I'm not ready to invest time to setup your DB with no any demo site and then measure how it works.

Add a benchmarks and maybe demo site, to promote your solution.

[alexgleason]

I managed to throw together a half-assed preliminary benchmark and it looked like this:

benchmark                           time (avg)        iter/s             (min … max)       p75       p99      p995
------------------------------------------------------------------------------------ -----------------------------
NostrEvent insert (pglite)           3.94 ms/iter         253.6     (1.84 ms … 8.29 ms) 5.5 ms 7.96 ms 8.29 ms
NostrEvent insert (SQLite)         253.46 µs/iter       3,945.5   (181.44 µs … 1.21 ms) 269.25 µs 503.35 µs 602.24 µs

This is in the context of my own custom application in Deno. There are outside factors that would influence it, so it doesn't mean much. But I figured I'd share.

I also got a memory access error during the benchmark.

error: RuntimeError: memory access out of bounds
    at <anonymous> (wasm://wasm/02d347d2:1:367991)
    at <anonymous> (wasm://wasm/02d347d2:1:468423)
    at <anonymous> (wasm://wasm/02d347d2:1:289459)
    at <anonymous> (wasm://wasm/02d347d2:1:10259298)
    at <anonymous> (wasm://wasm/02d347d2:1:10345354)
    at ret.<computed> (file:///home/alex/.cache/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.0.1-alpha.2/dist/chunk-RM7SEAOI.js:5401:33)
    at invoke_vii (file:///home/alex/.cache/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.0.1-alpha.2/dist/chunk-RM7SEAOI.js:5764:9)
    at <anonymous> (wasm://wasm/02d347d2:1:5239529)
    at <anonymous> (wasm://wasm/02d347d2:1:8921170)
    at ret.<computed> (file:///home/alex/.cache/deno/npm/registry.npmjs.org/@electric-sql/pglite/0.0.1-alpha.2/dist/chunk-RM7SEAOI.js:5401:33)

[vitonsky]

Now i see why repository author prefer to hide performance details.

Thanks @alexgleason!

[thruflo]

The repository author is working on benchmarks and will publish soon.

There are quite a few aspects to consider — the storage mode, the workload, differences in optimal query patterns for SQLite and Postgres, etc.

It may be best to wait for an apples to apples comparison before drawing conclusions.

[vitonsky]

It may be best to wait for an apples to apples comparison before drawing conclusions.

The real world is not an anime, so usually another developers will not trust you and waste their time on your project if you have bad readme, no benchmarks and do not respond in issues in time.

Learn how to communicate with an open source community, if reputation are important for your project.

[AntonOfTheWoods]

@vitonsky I guess you are 18 or something... Have you seen how old this repo is? The number of stars in less than a month show the absolutely massive interest but there are only a couple of devs on this, and I didn't see any offers of help from you.

[vitonsky]

The number of stars in less than a month show the absolutely massive interest

It show that authors have 5$ to buy a github stars and time to post on HN and lobsters to get comments. So i not buy it.

but there are only a couple of devs on this, and I didn't see any offers of help from you

As i said, the real world is not an anime. If you need community help - be open for community first. Talk with people in issues, resolve community problems, maintain the code and documentation, create benchmarks.

Of course you will not get any help of people who do not interesting in your project, because they don't want to waste their time on project where 2 weeks old issue did not been responded by repository maintainers. Even this fact shows a low quality level on the project and say to me about potential problems if i would start use this project. If i will have some problems with this solution, i will create issue, waste 2 weeks in ignore, then somebody will appears in issue to attack my personality 🙂. No, thanks

[odinho]

Thanks a lot for the benchmarks, it looks like it does quite well!

So many potential use cases for this.

[samwillis]

Hey,

No worries, there is a second round of benchmarks I'm adding here: #55 (just finalising it)

There is a lot of opportunity to improve on this too, we've already improved the speed 2-3x from where it was at launch, and have a good idea where the next bottle necks are.

I'm aiming to publish a new version by the end of the week. (maybe tomorrow...)