Why? Existing options (Nessie, Polaris) are Java-based. I wanted something lightweight that runs alongside PostgreSQL without a JVM.

Stack:

- Go + Fiber framework

- PostgreSQL with pgx/v5 connection pooling

- Prometheus metrics built-in

Performance (Xeon 8581C): - ~24k req/s throughput

- 44μs p50 latency

- Linear scaling to 200+ concurrent connections

Multi-node:

- Run multiple instances behind a load balancer

- PostgreSQL advisory locks for leader election

- Background tasks coordinate automatically

Quick start:

  docker run -p 8181:8181 ghcr.io/teampaprika/bingsan:latest

GitHub: https://github.com/teamPaprika/bingsan

Docs: https://teampaprika.github.io/bingsan/en/

Happy to answer questions!

Comments URL: https://news.ycombinator.com/item?id=46775654

Points: 1

# Comments: 0

We use our Windows workstations as WSL SSH tunnels, protected with email verification (only for our domain), and it’s been working perfectly.

I’m curious, though, about how we can expose Docker services. It would be fantastic to have a remote build server set up with Cloudflare Tunnel.

Everything appears to be functioning smoothly, but I do miss the ‘transfer’ feature in Comlink. Although it wasn’t a critical feature, it was a nice one.

The best aspect of CapnWeb is that we can reuse most of the code related to clients, servers, and web workers (including Cloudflare Workers).

We’ve also added vector search to our product, which is really useful.

OpenAI’s official examples of embedding search use cosine similarity. But here’s the cool part: since OpenAI embeddings are unit vectors, you can just run the dot product instead!

DuckDB has a super fast dot product function that you can use with SQL.

In our product, we use duckdb-wasm to do vector searches on the client side.

We have also tried arrow js or parquet wasm, and they were much lighter than duckdb wasm worker.

DuckDb however was useful in our case, considering our nature as form builder service, we had to provide features for statistics. It was cool to have OLAPS inside a webworker that could handle (as far as we checked) more than 100,000 rows at ease.

The advantages of loading “parquet” in “client side” are that 1) you only have to load data once from server and 2) the parquet files are surprisingly well zipped.

1) If you load once from server, no more small network requests while you are scrolling a table. Moreover, you could use the same duckdb table to visualize data or show raw data.

2) Sending whole data as a parquet file is faster through network than receiving data as json in response.

On the other hand, let’s say we have to draw a chart from a column. The type chart could be changed by user - they could be Pie charts, means, time series chart, median, table or even dot products. To achieve this goal, we would bring just a column from s3 using duckdb, and apply sql queries from client side, rendering adequate ui.

Our team is currently building a form builder SaaS. Most forms have responses under 1,000, but some of them would have more than 50,000 responses.

So, when user tries to explore through all responses in our “response sheet” feature, usually they could be loaded via infinite scrolling (load as they scroll).

This uses up to 100MB of network in total if they had to get object arrays of 50,000 rows of data with 50 columns.

That was where duckdb kicked in : just store the responses into S3 as parquet file(in our case Cloudflare R2).

Then, load the whole file into duckdb-wasm into client. So when you scroll through sheet, instead of getting rows from server, you query rows from local db.

This made our sheet feature very efficient and consistent in terms of their speed and memory usage.

If network speed and memory is your bottle neck when loading “medium” data into your client, you definitely should give it a try.

PS. If you have any questions, feel free to ask!

PS. Our service is called Walla, check it out at https://home.walla.my/en