Re:Show HN: Velvet – Store OpenAI requests in your own DB
by elawler24 on Wednesday September 25, 2024 @11:45AM
(#41648681)
It's a standalone DB, just for LLM logging. Since it's your DB - you can configure data retention, and migrate data to an analytics DB / warehouse if cost or latency becomes a concern. And, we're happy to support whatever DB you require (ClickHouse, Big Query, Snowflake, etc) in a managed deployment.
Re:Show HN: Velvet – Store OpenAI requests in your own DB
by angoragoats on Wednesday September 25, 2024 @11:51AM
(#41648737)
I guess I should have elaborated to say that even if you're spinning up a new database expressly for this purpose (which I didn't see specifically called out in your docs anywhere as a best practice), you're starting off on the wrong foot. Maybe I'm old-school, but relational databases should be for relational data. This data isn't relational, it's write-once log data, and it belongs in files on disk, or in purpose-built analytics tools, if it gets too large to manage.
Re:Show HN: Velvet – Store OpenAI requests in your own DB
by elawler24 on Wednesday September 25, 2024 @12:16PM
(#41649017)
Got it. We can store logs to your purpose-built analytics DB of choice.
PostgreSQL (Neon) is our free self-serve offering because it’s easy to spin up quickly.
Re:Show HN: Velvet – Store OpenAI requests in your own DB
by philip1209 on Wednesday September 25, 2024 @03:18PM
(#41650902)
Philip here from Find AI. We store our Velvet logs in a dedicated DB. It's postgres now, but we will probably move it to Clickhouse at some point. Our main app DB is in postgres, so everybody just knows how it works and all of our existing BI tools support it.
Here's a video about what we do with the data: https://www.youtube.com/watch?v=KaFkRi5ESi8
There are plenty of other solutions (examples include Presto, Athena, Redshift, or straight up jq over raw log files on disk) which are better suited for this use case. Storing log data in a relational DB is pretty much always an anti-pattern, in my experience.