5/5. Together, these changes have made using ParadeDB (we think) significantly easier. You can check it out at docs.paradedb.com. We'd love to hear your feedback on the new API.

And of course, don't hesitate to give us a star ⭐

4/5. We came up with two ideas:

- Tokenizers as Postgres types. This makes tokenizers a first-class construct in Postgres.

- Custom operators. Inspired by pgvector, we changed a few of our functions to be custom Postgres operators.

3/5. As our adoption grew, we noticed two things:

- Defining tokenizers (a critical component of full-text search) was confusing

- ORM integrations were difficult

Developer experience is critical to any database, and so we had to fix this.

2/5. Our initial API was JSON-based. Inside Postgres, that felt... odd. But there was a reason.

Elastic is JSON-based, and so are Lucene and Tantivy (our underlying search engine). We focused on exposing powerful search features, but not so much on their ergonomics.

7/7. We love feedback. Give it a try at docs.paradedb.com and let us know how it goes.

We've got a lot of good stuff coming (did somebody say faster JOINs?) and are excited to build upon these features to deliver a truly SQL-native Elasticsearch alternative.

6/7. Using the proper tokenizers is critical to all complex search workloads and we've seen a large improvement in developer velocity with this new SQL interface.

It's also laying the ground work for us to integrate with ORMs, which is perhaps our second most requested feature.

5/7. Last but not least, we've revamped our SQL interface. We've introduced a few new SQL operators to simplify queries, and have made tokenizers a first-party construct in SQL. Stemmers are tokenizers are now defined at the index creation time and can be customized as needed.

4/7. Our customers are growing, and with that ParadeDB needs to ingest faster. So we've improved our ingestion speed by an order of magnitude.

In prod, we see 70,000 UPDATEs/minute with no perceived indexing latency.

3/7. If you've tried to do a COUNT(*) query in Postgres, you know it's slow. Go-get-a-coffee-and-come-back level of slowness.

ParadeDB's facets solve this problem. Regular COUNT(*) accelerated by our index, orders of magnitude faster. This has been our most requested feature.

2/7. Facets are a critical part of search. For those not familiar, facets are aggregates over search results. Common examples include:

- "Top N + Count" (e.g. Give me the top 10 results, and tell me how many results there are)
- "Bucketing" (e.g. Give me all keyboards under 50$)

nice post :)

Classic

All good, I think we're still a step before doing that