marcklingen

Many great points/ideas here and on Discord, thanks HN!

For those reading this thread later, feel free to reach out with any feedback or questions marc at langfuse dot com

Got it, appreciate the clarification.

(1) yes, that's what many of our users are doing while swapping might refer to changing model parameters, prompts, embedding stores, embedding parameters, or splitting a "layer" into multiple (parallel) steps. Alternatively when experimenting on a higher "layer", we often see wildly different implementations that are experimented with over time. We added version and release tagging which to build dashboards on the impact of these experiments on quality/latency/cost (currently in alpha, we will release it soon).

(2) I see how metadata propagation could be much more elegant via OTel. Currently the metadata fields on traces/span and filtering based on them kind of does the job but I see how it could be much easier to ingest and use. Thank you!

Thx. Currently looking deeply into how we can make it as dynamic as possible to help people experiment with configurations and test on production samples. What do you exactly refer to with levels/layer in stack? See multiple meanings that would all make sense to me and would love to learn more

Currently the project is all Postgres and the managed version is on Supabase. No scalability issues yet, we consider different OLAP options as we are mostly interested in faster analytical queries

Thanks for the hint. Having only one fully managed db seems to be interesting to reduce needs for joining across databases and less operations overhead (managing uptime, setting up infra for testing, CI etc.) on our 2 people engineering "team". Timescale is definitely on the list to be at least an intermediary solution that would be faster to adopt than migrating to e.g. ClickHouse over time. As you mentioned it, any obvious limitations to watch out for?

Next 12 to 13 migration could be interesting for our (open source) code base. Currently using tRPC, page router and next auth. Until now I did not push for the migration as it seemed rather complex and non-urgent.

Do you have learnings on for which kind of project setups the migration works well and for which it struggles?

Congrats on the launch! Played around with fastgen some weeks ago and liked the focus on creating APIs and workflows. I have built many API endpoints with Make.com in the past as it made it easier to manage external connections compared to using lambdas but felt limited by the Make.con data model.

How/when do you plan to

- catch up on integrations other workflow tools have already built? E.g. my workflows often rely on data in CRMs/Notion/GitHub.

- integrate with alternative databases and datawarehouses? I don’t necessarily want to sync all state to the fastgen-managed Postgres.