Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Velvet – Store OpenAI requests in your own DB

usevelvet.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#41

Post by elawler24 »

knowaveragejoe wrote: post #25
elawler24 wrote: post #7

Earlier quoted context omitted.

The self-serve version is hosted (it’s easy to try locally), but we offer managed deployments where you bring your own DB. In this case your data is 100% yours, in your PostgreSQL. That’s how Find AI uses Velvet.

Where is this mentioned? Is there a github(etc) somewhere that someone can use this without using the hosted version?

Right now, it’s a managed service that we set up for you (we’re still a small team). Email me if you’re interested and I can share details - emma@usevelvet.com.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#42

Post by elawler24 »

beepbooptheory wrote: post #39
bachback wrote: post #29

interesting, seems more of an enterprise offering. its OpenAI only for and you plan to expand to other vendors? anything opensource?

I guess I don't understand what this is now. If its just proxying requests and storing in db, can't it be literally any API?

We could support any API. We’re focused on building data pipelines and tooling for LLM use cases.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#43

Post by elawler24 »

bachback wrote: post #29

interesting, seems more of an enterprise offering. its OpenAI only for and you plan to expand to other vendors? anything opensource?

We already support OpenAI and Anthropic endpoints, and can add models/endpoints quickly based on your requirements. We plan to expand to Llama and other self-hosted models soon. Do you have a specific model you want supported?

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#44

Post by reichertjalex »

Very nice! I really like the design of the whole product, very clean and simple. Out of curiosity, do you have a designer, or did you take inspiration from any other products (for the landing page, dashboard, etc) when you were building this? I'm always curious how founders approach design these days.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#45

Post by elawler24 »

reichertjalex wrote: post #44

Very nice! I really like the design of the whole product, very clean and simple. Out of curiosity, do you have a designer, or did you take inspiration from any other products (for the landing page, dashboard, etc) when you were building this? I'm always curious how founders approach design these days.

I’m a product designer, so we tend to approach everything from first principles. Our aim is to keep as much complexity in code as possible, and only surface UI when it solves a problem for our users. We like using tools like Vercel and Supabase - so a lot of UI inspiration comes from the way they surface data views. The AI phase of the internet will likely be less UI focused, which allows for more integrated and simple design systems.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#47

Post by angoragoats »

I don't understand the problem that's being solved here. At the scale you're talking about (e.g. millions of requests per day with FindAI), why would I want to house immutable log data inside a relational database, presumably alongside actual relational data that's critical to my app? It's only going to bog down the app for my users.

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.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#48

Post by elawler24 »

TripleChecker wrote: post #46

Does it support MySQL for queries/storage - or only PostgreSQL? Also, caught a few typos on the site: https://triplechecker.com/s/o2d2iR/usevelvet.com?v=qv9Qk

We can support any database you need, PostgreSQL is the easiest way to get started.

Re: Show HN: Velvet – Store OpenAI requests in your own DB

#49

Post by elawler24 »

angoragoats wrote: post #47

I don't understand the problem that's being solved here. At the scale you're talking about (e.g. millions of requests per day with FindAI), why would I want to house immutable log data inside a relational database, presumably alongside actual relational data that's critical to my app? It's only going to bog down the app for my users. There are plenty of other solutions (examples include Presto, Athena, Redshift, or s…

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

#50

Post by angoragoats »

elawler24 wrote: post #49
angoragoats wrote: post #47

I don't understand the problem that's being solved here. At the scale you're talking about (e.g. millions of requests per day with FindAI), why would I want to house immutable log data inside a relational database, presumably alongside actual relational data that's critical to my app? It's only going to bog down the app for my users. There are plenty of other solutions (examples include Presto, Athena, Redshift, or s…

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.

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.
Post reply on HN