This is a practical guide for getting strong, repeatable results from SqlDBM AI Copilot.
1. Core Principles
• Treat Copilot as embedded, not adjacent. Use it inside existing modeling work, not as a parallel sandbox. The goal is faster iteration on real work.
• Reach for AI only when the deterministic feature does not fit. SqlDBM already handles many tasks natively (Forward Engineering, Environments, table templates, schema monitoring, the Post API, Excel upload, concurrent working). Use Copilot when the work is interpretive or the manual alternative would take hours.
• Set your role before you prompt. Architect, governance, BI consumer. The role changes the tone, the detail, and the suggestions you receive. If outputs feel generic, check the role first.
• Prompt in your working language. Copilot handles Spanish, Japanese, and other languages. Use whichever language helps your team express intent precisely.
2. Where Copilot Adds the Most Leverage
Copilot is strongest at interpretation, classification, and bulk reasoning across a model. It operates on the visual canvas: creating and editing objects, setting governance fields, writing documentation, and analyzing the project. It does not produce code. DDL comes from SqlDBM's Forward Engineering, which reads the model and emits deterministic, dialect-specific SQL. Copilot shapes the model; Forward Engineering generates the DDL.
• Model creation. Build physical, logical, or conceptual models in the canvas from business requirements, ERD images, files, or imported schemas.
• Bulk operations. Add, rename, or restructure columns across an entire project in one prompt. Standardize data types, label relationships, update governance fields in bulk.
• Schema transformation. Schema transformation can help generate initial mappings between modeling approaches (for example, normalized to dimensional or Data Vault), but these conversions require additional design decisions, especially when moving across architectural layers or replacing one modeling methodology with another. Convert between modeling patterns in a single prompt: normalized to dimensional, dimensional to Data Vault, and other directions.
• Documentation and translation. Improve logical names, generate descriptions, translate documentation into multiple languages.
• Governance and PII. Scan the model for PII/PHI, assign governance fields, add classification tags, etc.
• Interactive querying. Analysts and business users ask questions of the model in natural language. Accuracy depends heavily on documentation quality, well-documented models produce dramatically better answers.
3. What Not to Use Copilot For
• Code or query generation. No CREATE TABLE, ALTER, SELECT, dbt YAML, or pipeline code. DDL comes from Forward Engineering. Transformation SQL lives outside SqlDBM.
• Product navigation. “How do I create a project,” “where is the export button.” These are documentation questions, use the help center.
• Cross-project work. Copilot operates within a single project today. Cross-project context is on the roadmap.
• Massive DDL pastes. Thousands of tables hit limits and produce poor results. Use SqlDBM’s native reverse engineering, then prompt against the imported model.
• Sensitive data in prompts. No PII, no customer records, no production data values. Use representative metadata only.
• Final approval on governance decisions. Copilot drafts. A human with authority makes the final classification call.
The decision rule:
if a feature exists for the task, use the feature. Reach for Copilot when the work is interpretive (PII classification, descriptions, schema transformation), when it crosses many objects in ways the deterministic features do not cover well, or when the manual alternative would take hours.
4. Where to Use Copilot Inside the Platform
• Reverse engineering. Greenfield projects. Generate a model from a brief, an ERD image, a file, or DDL pulled from another platform.
• Object level. Targeted changes to a single table, view, or relationship. Impact analysis, refining one table’s columns, improving a single description.
• Project level. Bulk operations, schema transformations, project-wide analysis, interactive querying. Highest leverage, where review discipline matters most.
• Database documentation. The surface where context awareness pays off most. Logical names, descriptions, PII flags, multi-language translation.
5. Quick Reference
A side-by-side reference for the most common prompt patterns.
| DO THIS | NOT THIS |
|---|---|
| Build a Snowflake-targeted schema for an order management system with 8 tables in the canvas. Then use Forward Engineering for the DDL. | Write me a CREATE TABLE statement for an Orders table with these columns. (Standalone SQL, no model.) |
| Reverse-engineer this image file into the project so we can work with it. | Here is 5,000 lines of DDL pasted into the chat, please rewrite it for me. |
| Run the PII scanner across the Customer and Claimant tables and add a PII checkbox governance field. | Make this model GDPR compliant. |
| Apply Data Vault 2.0 naming conventions to all hubs, links, and satellites in this model. | Fix the names. |
| Convert this normalized model into a star schema with appropriate fact and dimension tables. | Make this model better. |
| Generate descriptions for every column in DIM_POLICY based on its name and data type, then translate them to Spanish. | Document the model. |
| Add audit columns (SOURCE_SYSTEM, LOAD_TIMESTAMP, RECORD_HASH) to all fact tables. | Add the usual audit stuff. |
| Perform an impact analysis on the Customer table before I rename CustomerId. | What happens if I change this? |
| Explain what FACT_CLAIM represents in plain language for a business analyst. | What does this do? |
| Operate within the active project; reverse-engineer external schemas before prompting against them. | Pull in the schema from our other project and merge it. |
6. Common Pitfalls
• Treating Copilot as a separate project. Lowest leverage. Copilot pays off when it is used inside work that was already happening, not as a parallel exercise.
• Skipping role selection. If outputs feel generic, the role is the first thing to check. Architect and BI consumer prompts produce different responses.
• Over-trusting bulk operations. Powerful means a single bad prompt affects many objects. Run against a copy or subset first, then apply broadly.
• Letting prompts drift across users. Inconsistent wording produces inconsistent output. Save shared pre-prompts, treat them as team assets.
• Underinvesting in documentation. Interactive querying accuracy is gated by documentation quality. Skip the documentation pass and Copilot’s answers feel inconsistent.
7. What Is on the Roadmap
• MCP server integration. Operate SqlDBM from outside the platform. AI agents, copilots, and downstream tools call the governed model directly. Ships in the next two weeks.
• Internal knowledge integration. Reference your company’s data dictionaries, source systems, and reference documents.
• AI release notes. Schema and platform changes explained in business-friendly language for non-technical stakeholders.
• Governance Agent. Proactive suggestions and surfacing untagged information that requires classification.
• Cross-project context. Copilot reasoning across the full modeling portfolio rather than one project at a time.
If a roadmap item would unlock something specific for your team, share that with your SqlDBM contact. Customer input directly shapes prioritization.