cevian

8 ms·

1.
Show HN: Pg-aiguide – Write better PostgreSQL code with AI(github.com)
3 points by cevian 10mo ago|0 comments
2.
Show HN: MCP server that teaches LLMs to write production grade Postgres SQL(github.com)
5 points by cevian 11mo ago|0 comments
3.
Show HN: An Open-Source Eval Suite That Helps You Fix Postgres-Based Text-to-SQL(tigerdata.com)
2 points by cevian 1y ago|0 comments
4.
Show HN: Making Postgres Self-Describing for LLMs with a Semantic Catalog(tigerdata.com)
2 points by cevian 1y ago|0 comments
5.
Evaluating general purpose vs. domain specific models for financial RAG(timescale.com)
3 points by cevian 2y ago|0 comments
6.
by cevian 2y ago
(co-author here) We automatically retry on failures in a while. We also log error messages in the worker (self-hosted) and have clear indicators in the cloud UI that something went wrong (with plans to add email alerts later). The error han
7.
by cevian 2y ago
(Post co author) We absolutely agree that chunking is critical for good RAG. What I think you missed in our post is that the vectorizer allows you to configure a chunking strategy of your choice. So you store the full doc but then the syste
8.
by cevian 2y ago
(post co-author here) It could do either depending on on what the planner decides. In pgvector it usually does post-filtering in practice (filter after vector search). pgvector HNSW has the problem that there is a cutoff of retrieving some
9.
by cevian 2y ago
as far as I can tell Chroma can only store chunks, not the original documents. This is from your docs `If the documents are too large to embed using the chosen embedding function, an exception will be raised`. In addition it seems that embe
10.
by cevian 2y ago
haha. We had a good internal debate as to whether this is more like indexes or more like Materialized Views. It's kinda a mixture of the two.
11.
by cevian 2y ago
(post co-author here) The DB is the right layer from a interface point of view -- because that's where the data properties should be defined. We also use the DB for bookkeeping what needs to be done because we can leverage transactions
12.
by cevian 2y ago
(post co-author here) We agree a lot of stuff still needs to be figured out. Which is why we made vectorizer very configurable. You can configure chunking strategies, formatting (which is a way to add context back into chunks). You can mix
13.
by cevian 2y ago
Please note that TimescaleDB also uses columnar storage for its compressed data. Disclosure: I am a TimescaleDB engineer.
14.
by cevian 3y ago
Hah! This was actually one of the main algorithmic challenges of adapting DiskANN to PostgreSQL. Yes, I think it's common for these algorithms to assume you know how many results to return ahead of time. But in PostgreSQL that's n
15.
by cevian 3y ago
This article doesn't account for the fact that the role of government funding in science is to fund basic science that industry doesn't have the right incentives to fund. Renewables and energy efficiency do just fine with industry
16.
by cevian 3y ago
Lead engineer here, happy to answer any questions
17.
by cevian 5y ago
Timescale [ Worldwide | Fully Remote | Multiple Roles: Eng, Product + more | https://www.timescale.com/ Timescale is continuing to grow rapidly, and we’re hiring for many roles involving distributed systems and databases
18.
by cevian 5y ago
Just one more note. Timescale is hiring, including for roles working on Promscale. https://www.timescale.com/careers Promscale roles are listed in the "Observability" section.
19.
by cevian 5y ago
(NB: Post author and Promscale dev here) Promscale does both data storage and analysis/rollups. It's like Thanos in that you can use it as a remote storage backend. It has the additional functionality of then aggregating/anal
20.
by cevian 5y ago
(NB: post author here) Great question. We support average of averages by storing the intermediate state of the aggregate (for average that's the sum and count) so we could cleanly re-aggregate. Eventually, we'll be able to increme
21.
by cevian 5y ago
(Timescale engineer here). We believe so and we have customers using us for just that. We haven't created our own product for that yet (as we have for metrics -- Promscale) but it is an idea we are playing with. You may want to look at
22.
by cevian 5y ago
That may indeed have been more accurate. But this is a HN comment thread after all, we can't capture all subtleties of a very complex debate. :)
23.
by cevian 5y ago
That's fair but I was more replying to the OP that said "but it shouldn't be called an Open Source license". The point is we don't call our license Open Source. Comparisons to Open Source and discussions of the pros
24.
by cevian 5y ago
That only makes sense if you agree with the open source foundation definition of restrictive. I don't. I think the ability to freely link to whatever other software is much more important to most people than the ability to run a *aaS.
25.
by cevian 5y ago
And we never call it Open Source! (Timescale engineer here)
26.
by cevian 6y ago
(Promscale Team Lead Here) Promscale, which connects Prometheus to TimescaleDB also handles high-cardinality well and allows you to use both PromQL and SQL for data analysis. I'd humbly suggest taking a look. Plus our PromQL implementa
27.
by cevian 6y ago
By the way, for those interested, our first community meeting is Next Wed Oct 14 @ 16:00 UTC / 12:00 EDT More info: https://tsdb.co/promscale-agenda
28.
by cevian 6y ago
(TimescaleDB engineer here) Some of the comments here sound technically off. We've never seen a backup take down a machine. The backups we use are the same as Postgres which are used by millions of companies without a problem (and can
29.
by cevian 6y ago
I see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my userna
30.
by cevian 6y ago
The access node is replicated using streaming replication and is thus not a SPOF.

More ›