u/InsideDebt6345

The setup wires a database's native /metrics endpoint into a Docker Compose stack with Prometheus and Grafana. The dashboard tracks the four signals that matter for vector search regardless of engine: request rate per endpoint, p95 latency, error ratio, and memory pressure (RSS alongside major page faults, which is the early warning for disk paging). Then eight alert rules for the failure modes that hurt, recovery mode, rebuild failures, latency, and fd exhaustion.

Okay, so I was trying to build a product using Lovable, and I'm confident that it will do well for the first few users if I ask for their feedback. And we all know what works best here, like dashboards, internal tools, approval flows, etc. You can ship fast and move on.

As always, the trouble starts when the app grows, and you keep hitting the edges of what the platform can do. One workaround becomes two, then three, and eventually you're spending more time adjusting to the platform than you'd have spent building it yourself.

Portability is there, too. Getting your data out is usually easy enough, but getting the app's logic, workflows, and integrations out is a different task in itself.

So what was the sign for you that a low-code app had outgrown its platform?

Was it customization, cost, security, performance, portability, or something else?

[ Removed by Reddit on account of violating the content policy. ]

I don't have a good heuristic for when to prioritize throughput over recall in a vector DB, and I want to see how others decide.

There's a 10M-vector benchmark going around: 768 dims, default HNSW, same hardware. Qdrant did ~23 QPS at 0.9985 recall. VectorAI DB did ~745 QPS at 0.9882 recall. big throughput jump, small recall drop.

For most LLM apps, I'd reach for Qdrant; as the recall is higher, it's simpler to run, and many RAG systems never get near 10M vectors, so the throughput ceiling isn't even in play. The speed only pays off at a scale plenty of teams don't even reach.

The high-QPS-at-scale case is where I'm unsure. If you're past 10M vectors and getting hammered with queries, does the extra throughput start outweighing that recall gap? Or do you stay on Qdrant and scale it out with replicas before you'd swap databases?

If you were picking:

- hard recall floor, then take the fastest db above it?

- or size for throughput first and use recall as the tiebreaker?

Just want to know if there's a rule of thumb here, or if it's profile your own workload every single time.

I have been checking on managed scraping APIs for a small project, but there's obviously a gap between wanting a reliable anti-bot bypass and getting handed a full enterprise data platform with a procurement process attached.

The project is a job board and some e-commerce, all behind Cloudflare. Maybe a few hundred thousand pages a month. What I care about is how fast I can get the first successful request out, what a request costs after retries and blocks, and whether I can scale up without a sales call or KYC.

Bright Data is the obvious heavyweight, and I'm not arguing with that. If I needed SERP at scale or SOC 2, I'd pay them and move on. But for job boards behind Cloudflare, it feels like a little too much.

So I've been poking at the self-service tiers of a few tools, like Scrapfly, ScraperAPI, and Zenrows. They all skip the sales-call part, but the billing models are more different than I expected, especially around whether failed requests count against you.

Anyone running a small workload somewhat like this? If yes, what are you using, and how has that been working out for you?

For a local setup, I think pgvector is the easy answer if you're already running Postgres. One extension, ACID, and you can filter with a WHERE clause instead of standing up a second service. For a local knowledge base, that seems like plenty. The catch is that it gets complicated once you're past a certain vector count or writes get heavy, index build time climbs, and latency goes with it. I've seen pgvector latency go from about 50ms to 800ms past the 10M mark, though that was on a big instance, not a local box.

What I can't tell is where the line sits for someone running this on their own hardware rather than a cloud node. Locally, you don't get to scale out of the problem, so the wall probably comes sooner.

For people running local RAG:

• What are you on, pgvector or something dedicated like Qdrant/Chroma/Milvus/VectorDB, and at what vector count did you pick?
• Did anyone start on pgvector and hit a wall on a local box?
• For a few hundred thousand to low millions of vectors, is a dedicated engine overkill locally?

I'm sure that in this SubReddit, many people might have figured this out. I mean, I get the pitch of no-code tools, as I believe in that too. You get something usable in front of people way faster than waiting on an eng cycle. For a first version, or if we are using a tool internally, it works great, but as always, when I look back after 8 months, more people depend on it, and now the requirements are pushing the platform to the edges of what it actually lets you do.

Here's what I keep seeing coming up:

• You can export your data, but not the app itself. So if you ever want out, you're rebuilding the screens, the permissions, the logic, all of it
• Pricing that's cheap at 5 users and not cheap at all once it's per-seat or per-record, and the app succeeded
• Security review is only as deep as whatever the vendor exposes. fine for a form, less fine when it's touching customer data
• the shadow-IT thing. Someone builds a genuinely useful tool, six months later, nobody remembers who owns it or what data it's sitting on

None of that makes no-code bad. It makes it a specific tool for a specific window. What I'm trying to figure out is where people draw the line in general.