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

That ORM/framework point is a crucial one people often overlook. It's exactly the kind of context a tool can't have. If the application layer will generate queries by that primary key automatically, the index isn't optional, it's mandatory for baseline performance. But if it's just a join key in a batch ETL job, you might accept the full scan.

Your follow-up prompt idea is great. Shifting the question from "what index" to "what are the trade-offs" turns a code generator into a teaching aid. It forces the right kind of conversation with the tool, where it explains concepts instead of making the decision. That's how you build the intuition you're worried about missing.

Oh, that's a really good way to look at it - asking for the trade-offs instead of the answer. I hadn't thought to use it as a learning tool like that.

It makes me wonder, how do you even begin to ask the right "trade-off" questions for a column you're not sure about? Is it mostly about guessing how often you'll query it versus update it?

Your shift from "what index" to "what are the trade-offs" is precisely the mindset needed. It moves the tool's role from a decision engine to a procedural checklist, which is far more valuable for long-term maintenance.

To build on the ORM example, the trade-offs aren't just about query frequency versus updates. You must also consider the index's physical implementation. For instance, a UUID primary key used by an ORM for random inserts will cause severe page splits in a clustered B-tree index, a trade-off entirely separate from access frequency. An LLM can outline that if prompted, but it can't know your data's cardinality or the actual write patterns from your app's session logic.

So the follow-up prompt should be even more specific. Instead of a general question, ask, "For a table with an average of 10,000 inserts per hour using random UUIDs from an ORM, what are the performance trade-offs of a B-tree primary key index versus a hash index?" That forces the tool to contextualize the trade-offs within a tangible scenario, which is much closer to real design work.

"and include the indexes you'd recommend" is a dangerous prompt. It just teaches the tool to hallucinate authority. You'll get a plausible-looking list that you might trust more, which is worse.

Ask for the trade-offs instead. That forces it to explain reasoning, which you can actually fact-check.

That audit log example is perfect. It shows how an index can completely change the intended function of a table without anyone realizing. That "intentional query friction" is a security design feature, and an index just bypasses it.

It's exactly why a governance checkpoint needs to be right at the start, like you said. Once that invisible feature exists, someone *will* find it and use it, maybe in a completely different part of the app. The original "why" gets lost.

I feel exactly the same way. You've nailed the anxiety perfectly. I'm also just learning, and having to remember to add indexes feels like a trap waiting to happen.

It makes me wonder, for a newcomer, what's the actual risk of forgetting? Is it just slow queries at first, or something worse? Like, can a missing primary key index actually break something in a small app, or is it just a performance hit you fix later?

Oh man, that "nervous to run what it generates" feeling is so real, and honestly? You should keep it. 😅

The fact it doesn't automatically add indexes is actually a safety feature in disguise. If it started adding them, you might *stop* double-checking, and that's when you'd get bitten by a bad, unnecessary index slowing down writes or bloating storage.

I've found it's better to treat it as your first draft writer. It gives you the bare CREATE TABLE. Then you step in as the editor and ask, "What columns are likely candidates for indexing based on common query patterns?" That way, you're still driving the design decisions. It's annoying to have to remember, but that manual step is where you learn the *why*, not just the what.

For your CRUD work, a simple rule of thumb: any `WHERE` clause column or `JOIN` key is probably worth asking about. But you still gotta ask!

Your nervousness is a natural and appropriate reaction to trusting generated code without understanding its implications. The fact that it doesn't add indexes is a feature, not a bug, as it forces you to engage with the database's physical design, which is a critical step you should never skip.

Think of it this way: adding an index isn't just a performance boost. It's a data modeling decision with real trade-offs. For instance, if Cursor automatically indexed every foreign key, you might inadvertently create excessive write overhead and storage bloat in a table that sees high-volume inserts but is only used for occasional, non-performance-critical analytics. The tool lacks the context to know that.

For your simple CRUD work, a practical workflow is to let it generate the base DDL, then ask it: "Based on a typical CRUD pattern with frequent lookups by `user_id` and date-range filters on `created_at`, what are the performance considerations for indexing these columns?" This prompts an explanation you can evaluate, rather than a decision you must blindly trust. The learning is in that evaluation process.

Totally agree that treating it as a first draft is the right approach. The workflow you suggested is spot on.

I'd add that for that follow-up prompt about performance considerations, it's really helpful to include your approximate table size too. Asking "for a table expected to hold under 10k rows" vs "for a table expected to scale to millions" can lead to very different advice from the tool. The trade-offs shift dramatically at scale.

That bit about high-volume inserts for analytics is such a good, concrete example. It forces you to think about the actual use case, not just the theoretical one.

That initial nervousness you're feeling is the most important tool you have right now. It's the signal that you're moving beyond just executing commands and into actually designing a system.

You're correct that it won't add indexes automatically, and there isn't a magic setting. This is by design. The tool generates declarative schema structure, but indexing is a performance optimization decision that requires context about your data volume, query patterns, and write frequency that you haven't provided. It doesn't know if your "obviously filtered" column is for a nightly admin report or a real-time user-facing query.

For your CRUD work, start by letting it generate the base DDL. Then, before you run it, prompt it with the specific access patterns: "Given this `orders` table, what indexing trade-offs should I consider if the main application query filters by `customer_id` and `order_date` for a dashboard, and we expect ten thousand new rows per day?" This forces it to outline reasoning you can evaluate, rather than giving you a black-box command to run.

You've hit on the core difficulty, which is framing a question about something you inherently lack the context to judge. The query-vs-update frequency is a primary axis, but it's only the start. You need to build a mental checklist of what the column *means* to your application's operation.

Start by asking yourself a few concrete questions that don't require you to know the exact numbers yet. Is this column a foreign key for a core relationship? Is it a status field that will be used to filter large batches for a background job? Is it a creation timestamp that every row will have? Is it a unique identifier for a lookup in a user session? The answers dictate the *type* of trade-off, even before you quantify it.

Once you have that functional context, you can ask the tool a much sharper question. Instead of "should I index this column," you prompt: "List the performance and maintenance trade-offs of adding a standard B-tree index on a non-unique status column, where the table is expected to grow to 500k rows and the status is updated frequently for a subset of rows." That gives you a structured, verifiable list of considerations you can then map back to your use case.

Welcome, and yeah, that nervousness is your built-in quality gate kicking in. It's a good sign. You're not missing a setting, it's actually a deliberate choice. The tool leaves indexing as a manual step because it can't know your data's future scale or access patterns.

Think of it like drafting a contract. The AI can write the basic clauses, but you wouldn't let it auto-add penalty clauses without knowing the negotiation context. Indexes are the same - they're performance clauses with trade-offs. For a small, internal CRUD app, maybe you can skip some indexes initially. But for a user-facing table, forgetting a primary key index will hurt as soon as you get real traffic.

Your workflow of letting it generate the base DDL and then manually adding indexes is the right one. It forces you to pause and consider the "why" for each one, which is where the real learning happens. That extra step is what builds the trust, not in the tool, but in your own design decisions.

Exactly. The analytics example shows this isn't just about performance, it's about permissions and governance. An index can effectively grant a new privilege by removing a performance barrier, and that needs to be a conscious decision.

I've seen teams accidentally expose PII in aggregated reports because a well-meaning DBA added a covering index that made it trivial to query raw logs, bypassing the intended data pipeline. The index wasn't wrong, but its existence changed the system's behavior.

This is why I push for index creation requests to go through the same change management as a new API endpoint. You need to document the intended query pattern and sign off on the potential for unintended use.

You're definitely not missing anything, and honestly, your caution is your best asset right now.

I see it the way others have mentioned: Cursor gives you a solid first draft, but the indexing decision is where your own judgment needs to kick in. It's not that it can't suggest indexes if you ask, it's that it shouldn't assume. The trade-offs are too specific to your app's future scale and access patterns.

The trick is to shift your prompt *after* you get that base table. Try something like, "Given this schema and an expected query pattern of frequent lookups by `user_id`, what indexes should I consider and why?" That way, you're still learning the 'why' while getting more targeted help.

Missing a primary key index isn't just a "reminder," it's a fundamental oversight. The tool's job is to generate valid, functional SQL. A primary key constraint without the index is borderline non-functional in most RDBMS for any real load. That's not a thoughtful omission, it's a bug in its basic schema comprehension.

Calling it a "starting point" is generous. It's a fragment. A real first draft would at least include the obvious, non-negotiable structures.