Hacker News Reader

Superset would be on my shortlist if I had to use something else, but the join limitations were part of why I passed.

totalhackon Groq runs Mixtral 8x7B-32k with 500 T/s

Thanks! I did notice the queue count showing up occasionally but not every time. Maybe someone could repeat the test who has access without the queue so we can get an understanding of the potential latency once scaled and geo-distributed. What I'm really trying to understand is time to first token output actually faster than GPT 3.5 via API or just the rate of token output once it begins.

totalhackon Groq runs Mixtral 8x7B-32k with 500 T/s

Where is the data center located? The fastest response time I could get from some quick testing from the northeast US, having it output just one letter, was 670ms. Just wondering if that's an expected result, as it's on a par or slower than GPT 3.5 via API.

totalhackon Multi-database support in DuckDB

What are the performance implications, if any? I assume it's just translating queries as needed into the database engine language, in which case I wouldn't expect much of a performance issue.

totalhackon Let's talk about joins

Thanks! I'm not sure if I'll have the bandwidth to help yet, but interested to hear about the problem you are facing. I'll reach out this week.

totalhackon Let's talk about joins

I've also been frustrated when testing out tools that kinda keep you locked into one predetermined view, table, or set of tables at a time. I made a semantic data modeling library that puts together queries (and of course joins) for you as it uses a drill-across querying technique, and can also join data across different data sources in a secondary execution layer.

https://github.com/totalhack/zillion

Disclaimer: this project is currently a one man show, though I use it in production at my own company.

totalhackon Vanna.ai: Chat with your SQL database

Sure, AI will assist more and more in the cases where people must write SQL or manage a database, perhaps to the point you suggest.

But my point was actually that more people think they need to know SQL today than is actually the case. Excluding people that manage databases or cases that go direct to SQL for things like complex ETL, your average business user / marketer / etc should not be asked to write SQL or have to ask someone else to write SQL for them. Use a semantic layer instead with a UI on top and it's almost as easy as natural language.

Here is a example of one I made below, but there are others out there with more support. At my company, and the last few I've worked for, we use this approach for ~all day to day querying and a chunk of backend SQL replacement.

https://github.com/totalhack/zillion

totalhackon Vanna.ai: Chat with your SQL database

Have you considered a semantic layer instead, or does it have to be a natural language interface?

totalhackon Vanna.ai: Chat with your SQL database

Maybe you could utilize views to make your EAV schema more friendly for the LLM? Whether that's realistic depends on the specifics of your situation of course.

totalhackon Vanna.ai: Chat with your SQL database

Sounds like you are describing a semantic layer. You don't need AI to achieve that, though it is fun when it works. Example of a semantic layer I made below, but there are others out there with more support behind them.

https://github.com/totalhack/zillion

totalhackon Vanna.ai: Chat with your SQL database

This somewhat already exists in the form of semantic layers, which if done well can handle many of the queries necessary in the course of business without business users needing to know any SQL. There will still be cases where you need direct SQL, and AI tools can help the development process there at a minimum.

totalhackon Vanna.ai: Chat with your SQL database

I think AI to direct SQL will have use cases, but I personally have found it more of a fun toy than anything close to the main way I would interact with my data, at least in the course of running a business.

I am a fan of a semantic layer (I made an open source one but there are others out there), and think having AI talk to a semantic layer has potential. Though TBH a good UI over a semantic layer is so easy it makes the natural language approach moot.

https://github.com/totalhack/zillion

totalhackon The GPT Store

My best use case so far has been to make GPTs for a particular tech stack specific to a project I might be working on for a couple months. Saves a lot of re-prompting to build context. Seems like they understand this type of use case as valuable since they allowed internal-facing GPTs you can share in the Teams setup. So you could easily create a GPT with access to an internal wiki, code, project context, business processes, etc.

totalhackon Jeff Lawson steps down as CEO of Twilio

Twilio is great and super frustrating at the same time. I've run into outdated or missing documentation, and plenty of low hanging fruit UI improvements that get ignored. They seem to be asleep at the wheel at this point.

totalhackon An app can be a home-cooked meal (2020)

A friend and I recently created an app to track realtime scores for a high school reunion fantasy draft (we drafted teams with a few friends and you get points if the person shows up).

With AI helping it really lowers the barrier to personal or one-off apps you wouldn't otherwise have time for. We did the app in the framework he was comfortable with, which I hadn't used, and I wrote all my code with AI.

I got smoked in the game though.

totalhackon Show HN: Heynote – A dedicated scratchpad for developers

I use org mode which was great in emacs but the plugin kinda sucks for VS code. The main feature there is the ability to fold and nest sections.

I see you have a "blocks" concept which seems roughly equivalent to a top level foldable bullet in org mode. Are blocks nestable? Otherwise what is the recommended way to organize a multi-block set of notes? Typical example for me might be tackling a larger problem/feature (top level block) and then having sub blocks/bullets for each part of the problem which are also foldable. I usually don't go more than a few levels deep but could get by with just 2 if need be.

totalhackon The new local data stack: Integrating Dagster, dbt and DuckDB

+1 for using a semantic layer. I built (and open-sourced) one for use in my own business but Cube looks well done.

https://github.com/totalhack/zillion

totalhackon Accidental database programming

Have you ever looked at adding a semantic layer on top of a db for those that prefer to avoid direct SQL?

totalhackon Frigate: Open-source network video recorder with real-time AI object detection

Mind providing more details about the hardware in your setup, cameras etc?

totalhackon Grist is a modern, relational spreadsheet

Would this be embeddable in something like a custom chatgpt-style app? Say I wanted any tabular data that I'm interacting with to be a grist spreadsheet, for example. How many rows can it handle before the browser starts to feel sluggish? And how many grist tables in a single chat would start to cause issues?

totalhackon Ask HN: Show me your half baked project

https://github.com/totalhack/zillion

Semantic data warehousing and analytics tool written in python. It has experimental/half-baked NLP features to query your warehouse by interacting with the semantic layer with AI, instead of the normal approach of having an LLM write SQL and needing to know your entire schema.

totalhackon Choosing vector database: a side-by-side comparison

It was a while ago now so the details have faded, but for one all of the docker services it had to spin up vs the single container that qdrant runs. I'm sure there is a reason for this, but I haven't needed it.

totalhackon RAG is a hack

I'll just add that there are use cases where the extra layer actually adds a nice element of control and visibility. Adjusting a prompt to a black box LLM can sometimes lead to unpredictable results, though that can be mitigated with a good test set to some extent.

totalhackon Choosing vector database: a side-by-side comparison

I'm interested to try some of these others next time around, but I've used qdrant self-hosted in two projects and been pleased. Milvus was recommended so I gave that a try but found it over complicated. Pgvector seems like an obvious choice if you are already using postgres and if that performance is ok.

totalhackon Yandex open sourced it's BI tool DataLens

Looks pretty neat. Having not fully investigated it yet, I will say the one thing I usually run into with this and other BI tools is a lack of flexibility in the UI for forming queries. It's sometimes limited to one table or view at a time. I wonder why more of them don't use more flexible querying techniques, perhaps just due to the risk of a bad query being formed?

My preferred approach is implemented in Zillion, which I use for BI at my company: https://github.com/totalhack/zillion

totalhackon Yandex open sourced it's BI tool DataLens

I must like to live dangerously. In all seriousness though there are low cost alternatives to those mega BI tools that suit many use cases. If I wasn't rolling my own I'd probably start with Metabase or Superset. What I use: https://github.com/totalhack/zillion

totalhackon SQL Join Flavors

How about an LLM talking to a semantic layer that then writes the SQL? I added experimental support for that in a project of mine, but using a semantic layer makes most querying so simple that natural language based approaches just seem kinda silly unless you have interface constraints (like on a mobile device).

https://github.com/totalhack/zillion

totalhackon Relational is more than SQL

IMO a semantic layer is a nice UX/DX improvement over plain SQL in a business/analytics setting. I use a semantic layer* for >95% of use cases and fall back to SQL when needed. This balance will be different for each business of course.

* https://github.com/totalhack/zillion

totalhackon Relational is more than SQL

There are also ways to add some flexibility into a "fixed" schema when you need it. Entity-attribute-value tables, views, JSON columns (as a last resort), or a semantic layer like https://github.com/totalhack/zillion

totalhackon Fine-tuning GPT-3.5-turbo for natural language to SQL

I think there are probably a million posts and papers talking about text to SQL as it's a problem that's been tackled for a long time now...just with more vigor recently now that LLMs provide an improved/shiny approach. I think many companies now offer or consider themselves semantic layers in some fashion (google "semantic layer" + tableau, cube.dev, dbt...). I have not come across any blog or paper comparing text-to-sql directly to text-semantic-api. Certainly the latter is not as flexible as the former in that it can't produce every possible SQL query. In practice (for me at least) that's often not necessary, or is necessary rarely so you just do your direct SQL as needed and use your semantic layer >95% of the time.