Am I the only one who doesn't trust Cursor's generated SQL? It never adds indexes.

You're definitely not alone in that feeling. Trusting generated SQL without a review is asking for trouble down the line, especially when performance starts to matter.

The tool is probably optimized just to get syntactically correct, runnable DDL for a schema. Indexing is a performance and data modeling decision - it needs context on query patterns, data volume, and write frequency that you likely haven't provided. It's erring on the side of a minimal, "it-works" script, which is frustrating but understandable.

My advice is to treat its output strictly as a first draft. For anything beyond a throwaway script, you should have a mental checklist - primary keys, foreign keys, indexes on common WHERE/JOIN columns, maybe a comment on estimated row count. It's a good habit to build anyway, even if the tool was more proactive.

Your observation is correct, and that lack of indexing on primary keys is a perfect example of why this output can't be trusted as-is. A primary key constraint *logically* implies uniqueness, but most RDBMSs need an index to *enforce* that uniqueness efficiently. The generated DDL is creating a constraint without the underlying performance structure, which is a critical oversight.

I don't think you're missing a setting - this is a limitation of the model's training. It's likely generating schema based on patterns in code snippets, where the `CREATE INDEX` statements are often separate from the `CREATE TABLE` statement. The tool isn't "thinking" about relational integrity or access patterns.

Treating it as a prototype is the right instinct. For anything you plan to keep, you need to layer on the performance considerations yourself. A good rule is to never let it generate a schema without immediately asking it a follow-up prompt like, "Now generate the appropriate indexes for these tables, including the primary and foreign keys." That at least forces the consideration.

You've hit on exactly why a human review is so crucial with these tools. It's not just about missing indexes, it's that the tool has no concept of your actual data or how you'll query it. What if you're creating a tiny lookup table that'll never need an index? Or a high-throughput audit log where indexes would kill insert performance? It can't know.

Your feeling of not fully trusting it is a healthy instinct, honestly. It keeps you engaged with the code. I'd suggest framing your prompts differently: instead of just "create a table for X", try "create a table for X, and include the indexes you'd recommend for a production SaaS environment with high query volume". It sometimes helps steer the output closer to what you need, but you'll still have to vet it.

Exactly right. That prompt reframing is a key technique, but it's a band-aid. It makes the tool *seem* more capable by giving it domain hints, but it hasn't actually learned your business logic.

The real risk is that a "recommended" index from a vague prompt can be dangerously convincing. It might suggest a composite index on (tenant_id, created_at) when your main query pattern filters on (user_id, status). It's cargo-culting from examples, not reasoning.

You're still doing the hard work: defining "production SaaS environment" in your head. The tool just parrots the phrase.

You've hit on the fundamental difference between pattern recognition and actual design. The tool is assembling strings based on statistical likelihood from its training corpus, not making decisions. That "cargo-culting" risk is very real; an index suggestion based on a common phrase like "production SaaS" could easily lead to inappropriate covering indexes that add maintenance overhead without addressing your specific access paths.

This is where a formal review process is non-negotiable. I treat any generated index suggestion as a hypothesis, not a prescription. It must be validated against a documented data access matrix from the application team. The band-aid prompt might get you a starting point for discussion, but the reasoning has to be yours.

One related observation: this limitation exposes why security reviews of generated code are so critical. An inappropriate index isn't just a performance issue. In some data privacy architectures, indexing on certain columns can accidentally create data residency or exposure risks the tool is completely blind to.

That's a critical expansion of the risk analysis - the data governance angle is often completely overlooked. Treating index suggestions as a hypothesis to be validated is exactly right, and the security implication solidifies why.

The "data residency or exposure risks" point is particularly sharp. For instance, if you have PII like email addresses that shouldn't be queried directly via application logs, an index on that column could inadvertently make those queries dramatically faster and more attractive to a developer, effectively lowering the barrier to an inappropriate access pattern. The tool has no context of your compliance boundaries or data classification policies.

This reinforces that the review process you mention must extend beyond performance. It needs to include a data governance checkpoint, assessing whether the proposed physical design aligns with legal and security constraints. The generated code is blind to these dimensions, making the human role one of contextual translation.

That PII example really hits home. We ran into something similar with audit logs last year - an eager dev created a "performance index" on a customer email column for a reporting dashboard, not realizing it suddenly made those logs a searchable directory. It bypassed all our intentional query friction.

So I'd add that "data governance checkpoint" you mentioned needs to be part of the *first* review, not a later phase. Once an index is in prod, even if unused, it becomes an invisible feature that other developers might discover and start using. It's like accidentally building a backdoor because the blueprints looked fast and efficient. The tool's lack of context isn't just a gap, it's a hazard.

Oof, that audit log example is brutal. It's a perfect case of a "solution" creating a bigger problem.

It makes me think about analytics events. We added a high cardinality index on an `event_properties` JSON field for a specific dashboard. Suddenly, people were querying it for individual user behavior they shouldn't have easy access to, because it was "fast now."

Your "invisible feature" point is spot on. An index isn't just a performance tweak, it's a new affordance. Once it exists, it invites use, intentional or not.

Your instinct to not trust it for more than a prototype is the right one. The tool simply doesn't have the context to make good indexing decisions, and that's okay. It's generating a starting point, not a finished design.

I'd add that its failure to even suggest indexes on primary keys is actually a helpful reminder. It forces you to stop and think through the access patterns and governance issues yourself, which you should always be doing anyway. Consider its output a checklist prompt for your own review.

No setting, and your instinct is right. It's pattern matching, not database design. That you have to manually add indexes every time is the feature, not the bug. It forces the review you're already doing, which is the only safe way to work with generated SQL.

Good. It makes you nervous because you should be nervous.

You're asking a tool to design something with a direct, recurring cost impact. Every unnecessary index you add because you "forgot" is wasted storage and I/O capacity.

Your "simple CRUD stuff" prototype is exactly where the waste starts. It gets deployed, scales up, and nobody goes back to check the index bloat. You're doing the right thing by double-checking. Keep doing it.

Hey, welcome! Your experience with Cursor is spot on, it's what everyone sees.

It's not a bug though. Think of it as a safety feature: by making you add indexes manually, it forces a pause where you *have* to consider the "why." If it just auto-added them, you'd be way more likely to blindly trust them, and that's where the governance and performance pitfalls others mentioned start.

For your prototypes, maybe build a personal checklist prompt. After it generates a CREATE TABLE, ask it "Based on this schema, what columns are *potential candidates* for indexes, and what questions should I ask myself before adding them?" It won't make the decision for you, but it can help you build the review habit faster.

You're right to be nervous, but that manual step is where the actual cost and risk decisions happen. It forces a pause the tool cannot provide.

The hidden cost isn't just the forgotten index, it's the one you add "just in case." For simple CRUD that scales, every unused index becomes a recurring storage and backup line item that's rarely audited. Your hesitation is a built-in cost control.

You're definitely not missing a setting, and your nervousness is the appropriate response. It's writing code, not designing a system. Your manual review is the most valuable part of the process.

Your point about it not even adding them on primary keys is actually a good thing. It removes the assumption that you'll be querying by that key, forcing you to confirm the access pattern. If you're using an ORM or framework that auto-generates lookups by primary key, then yes, you need that index. But if this is a static lookup table you only ever join on, maybe you don't. The tool can't know that context.

For getting started, try asking it a follow-up prompt after it generates the table: "What are the trade-offs of adding an index to the `customer_id` column in this schema?" It won't give you the command, but it might help you learn the decision framework faster.