DEV Community: Rakesh Tanwar

CERT-In Log Retention for Databases and What I Would Log Without Creating a New PII Risk

Rakesh Tanwar — Thu, 03 Sep 2026 08:14:17 +0000

Logging is one of the best tools we have for investigating database security incidents.

It can also become a new sensitive-data repository if teams record everything indiscriminately.

India's CERT-In directions require covered entities such as service providers, intermediaries, data centres, body corporates, and government organisations to enable logs of ICT systems and securely maintain them for a rolling period of 180 days within Indian jurisdiction.

I do not interpret that as an instruction to copy every piece of personal data into logs.

Good security logging records enough evidence to reconstruct important activity without turning the logging platform into a second uncontrolled database.

Log the event, not the entire customer record

Suppose an application queries a customer's account.

For security investigation, I may need to know which application identity connected, when it connected, where it connected from, which database it accessed, whether authentication succeeded, and what privileged activity followed.

I usually do not need the customer's complete profile copied into the log line.

This distinction is fundamental.

Logs should describe activity.

They should not duplicate business data unless there is a specific justified reason.

For organisations using a managed database platform, I would define database audit events alongside application and infrastructure events rather than logging without a data model.

Authentication events matter

I want visibility into successful and failed database authentication.

User or service identity.

Timestamp.

Source system or address.

Destination database.

Authentication result.

Relevant privilege context.

Repeated failures can expose brute-force attempts, broken credentials, or misconfigured services.

Successful access from an unusual source can be even more important.

What I avoid is logging passwords, connection secrets, private keys, or complete authentication tokens.

A log that contains secrets becomes an attack surface.

Privileged actions deserve strong visibility

Routine SELECT activity on a busy application can generate enormous log volume.

Privileged operations are different.

Role changes.

Permission grants.

Database creation.

Schema changes.

User creation.

Security configuration updates.

Backup changes.

Logging configuration changes.

Destructive administrative actions.

I want these events clearly attributable to an identity.

If an attacker obtains administrative access, investigators need evidence of what changed.

Query logging needs judgement

Logging every SQL statement can be useful in specific environments.

It can also capture sensitive values embedded directly in SQL.

A query might contain an email address, phone number, personal identifier, access token, or other data.

I therefore prefer parameterised application queries and logging strategies that separate query structure from sensitive parameter values where possible.

Fingerprinting or query identifiers can help with operational analysis without preserving every literal value.

Network metadata connects the story

Database incidents rarely happen entirely inside the database.

An application host is compromised.

Credentials are used.

Connections reach the database.

Data is queried.

Information leaves through another system.

Network records help reconstruct that path.

That is why I consider cloud networking and security controls part of database observability.

Database logs, firewall events, private-network records, authentication events, and application logs become much more useful when timestamps and identities can be correlated.

Time synchronisation is essential

An incident timeline is useless if every system disagrees about time.

Database server says 10.03.

Application says 10.08.

Network logs say 10.05.

Now the incident team has to guess which event happened first.

CERT-In's directions also address system clock synchronisation.

From an engineering perspective, accurate consistent time is basic observability hygiene.

Protect the logs themselves

Retention creates value only if logs remain trustworthy.

Restrict write and deletion permissions.

Encrypt storage.

Control administrator access.

Monitor attempts to change logging configuration.

Consider immutable or append-oriented storage for important audit data.

Separate ordinary application administrators from people who can erase security evidence where practical.

An attacker who compromises a database account should not automatically gain the ability to delete the logs that record the compromise.

Retention should have an end

If an applicable requirement calls for a rolling 180-day period, I would automate that lifecycle.

Keep the required evidence securely for the required period and delete it according to policy when there is no longer another lawful or operational need.

Keeping security logs forever does not automatically improve security.

It can create a larger archive of sensitive metadata waiting to be exposed.

Minimise PII before collection

The cheapest sensitive log to protect is the one you never created.

I ask teams to review every field.

Do we need a full email address or would an internal user identifier work?

Do we need the request body?

Do we need raw card-related data?

Do we need complete SQL parameters?

Do we need authentication tokens?

Usually, the answer to several of those questions is no.

Good logging is selective.

Capture identity, time, action, source, destination, outcome, privilege changes, security-relevant database events, and enough context to investigate incidents.

Do not use regulatory retention as an excuse to collect unnecessary personal data.

That produces better forensic evidence and a smaller privacy risk at the same time.

DPDP Data Deletion vs Database Backups and What Happens After a User Asks You to Erase Their Data

Rakesh Tanwar — Thu, 03 Sep 2026 08:09:16 +0000

The hardest part of data deletion is rarely deleting one row from the production database.

The difficult part is understanding every place that row travelled.

Primary databases
Read replicas
Search indexes
Caches
Analytics stores
Logs
Queues
Warehouses
Snapshots
Backups

Once data has been copied into several systems, a user deletion request becomes a lifecycle problem rather than a SQL command.

For Indian organisations preparing for the substantive DPDP obligations scheduled for May 13, 2027, I think this is exactly the kind of engineering work worth starting before enforcement reaches the application team.

First understand the timeline

The DPDP Rules were notified in November 2025, but key substantive obligations are being introduced in phases.

As of September 2026, teams should not describe every right and erasure workflow as if the full compliance date had already arrived.

The practical opportunity is preparation.

Map where personal data exists now so the organisation is not building deletion infrastructure under deadline pressure later.

Production deletion is the easy part

Imagine a user asks to erase an account.

The application identifies eligible personal data and deletes it from the active relational database.

That might take seconds.

But the same user's information may also exist in backups taken yesterday, last week, and last month.

Immediately rewriting every immutable historical backup whenever one user submits a request can undermine the integrity and operational simplicity that make backups reliable.

This is why privacy engineering and backup engineering must be designed together.

A managed database platform should fit into an organisation-wide retention model rather than becoming an isolated copy of personal data.

Backups need a defined lifecycle

I prefer explicit backup retention.

Keep backups only as long as they have a legitimate operational or legal purpose.

Apply automatic expiration.

Control access tightly.

Encrypt them.

Do not use historical backups as convenient secondary datasets.

The shorter and clearer the backup lifecycle, the easier it becomes to reason about personal data inside historical copies.

Indefinite backup retention is difficult to defend operationally even before privacy requirements enter the discussion.

Restoration is the moment many teams forget

Suppose a user's active data was erased on Monday.

On Friday, the production database suffers a major incident and the organisation restores a backup created on Sunday.

The erased user's data may reappear.

This is the part I want teams to design for.

A deletion ledger or equivalent mechanism can preserve the knowledge that certain data was previously erased.

After restoration, the system can reapply deletions that occurred after the backup was created and before the restored production point.

The exact design depends on the application and legal basis.

The principle is that recovery should not permanently undo privacy operations.

Separate active use from recovery-only copies

A backup should not become a shadow production database.

Restrict who and what can access it.

If personal data remains temporarily inside an unexpired recovery copy, the organisation should ensure that copy is not used for marketing, analytics, customer support searches, or unrelated processing.

This separation reduces risk.

It also makes the purpose of retaining the backup much clearer.

Deletion needs to propagate beyond SQL

Applications increasingly use many data systems.

A user profile may be stored in PostgreSQL.

The session is in Redis.

Events are in Kafka.

Search data sits somewhere else.

Analytics receives another copy.

Object storage contains uploaded files.

Deleting only the relational row leaves a fragmented identity behind.

I create a data map linking personal-data categories to every downstream processor.

That map becomes the foundation for deletion orchestration.

Logs need special treatment

Teams often write personal data into logs without noticing.

Email addresses
Phone numbers
Tokens
Query parameters
Request bodies
Database errors containing user data

These logs can have completely different retention policies from the main database.

The best deletion strategy is often not to put unnecessary personal data there in the first place.

Data minimisation makes future erasure dramatically easier.

Infrastructure scaling should not create invisible copies

Cloud systems make cloning easy.

Development teams create database snapshots.

QA teams copy production datasets.

Engineers export tables to debug incidents.

Analytics teams create temporary stores.

Every copy increases deletion complexity.

I want policies around cloning and test data built into cloud infrastructure operations rather than depending on individual engineer judgement.

Masking and synthetic test data can eliminate many unnecessary personal-data copies.

Build the deletion system as a workflow

I think of erasure as a state machine.

Request received
Identity verified
Legal and retention requirements checked
Active systems identified
Deletion jobs triggered
Downstream systems updated
Evidence recorded
Backup-restoration handling preserved
Completion communicated

Some data may need to remain where another law requires retention.

That is why engineering should implement policy rather than invent policy.

Legal and privacy teams determine what may or must be retained.

Database engineers make that decision technically enforceable.

The backup question does not make privacy deletion impossible.

It simply proves that data lifecycle management must include recovery systems.

Prepare that architecture before the first high-pressure request exposes how many copies your organisation forgot it created.

Kubernetes vs Virtual Machines for Enterprise Workloads

Rakesh Tanwar — Tue, 11 Aug 2026 12:33:11 +0000

I think the Kubernetes versus virtual machine debate starts with the wrong assumption.

It assumes enterprises need to pick a winner.

I do not see Kubernetes and VMs as competing technologies in quite that way. Virtual machines abstract infrastructure. Kubernetes abstracts applications and their lifecycle. In fact, plenty of production Kubernetes clusters run on virtual machines.

That distinction changes the conversation completely.

For me, the goal is not to eliminate VMs because Kubernetes feels newer. It is to stop using machine-centric infrastructure where application-level orchestration creates measurable value.

Some workloads genuinely benefit from Kubernetes. Others are perfectly happy inside a VM and would probably prefer not to be disturbed.

Kubernetes and VMs Are Not Really Competitors

The architectural difference becomes much clearer when I stop thinking about containers and machines as interchangeable deployment formats.

At a practical level, this is how I separate them.

A VM gives an application a machine-like environment with its own operating system.

Kubernetes works higher up the stack. I describe the application state I want, such as six healthy replicas, and the platform continuously works to maintain it.

That is why a Kubernetes cluster running on VMs is not contradictory at all.

The VM abstracts the hardware. Kubernetes abstracts the application from those machines.

Kubernetes Wins When Applications Change Constantly

I see Kubernetes delivering its biggest advantage when change is normal rather than exceptional.

Microservices, APIs, SaaS platforms and customer-facing digital applications rarely sit quietly for six months. Teams deploy frequently, traffic changes throughout the day and individual services fail independently.

Kubernetes was designed for exactly this environment.

Rolling deployments, horizontal scaling, service discovery, scheduling and automated recovery allow teams to think less about individual servers and more about desired application state.

That operating model matters more to me than saying containers start faster than VMs.

In traditional infrastructure, I might spend time thinking about which server runs an application.

With Kubernetes, I care that the application has enough healthy instances and capacity. Which exact machine happens to run a particular replica becomes less interesting.

For applications that change constantly, that abstraction is incredibly useful.

VMs Still Make Sense for Plenty of Enterprise Software

I do not consider VM-based workloads outdated simply because they are not containerized.

Enterprise estates contain ERP platforms, older Windows applications, commercial software, virtual appliances, licensed products and applications built around very specific operating system assumptions.

These workloads often have one thing in common. They were designed to behave like they own a machine.

A VM handles that expectation beautifully.

Could some of these applications be placed inside containers? Probably.

Would that automatically make them modern? Not really.

Putting a twenty-year-old monolith into Kubernetes can sometimes produce a twenty-year-old monolith with a considerably more complicated deployment process.

If an application changes twice a year, meets its availability targets and costs relatively little to operate, I need a stronger reason to migrate it than Kubernetes is what modern companies use.

Modernization needs an outcome, not a fashion statement.

Kubernetes Can Improve Utilization but Is Not Automatically Cheaper

Cost is where Kubernetes discussions can become surprisingly optimistic.

Containers generally have a smaller infrastructure footprint than full virtual machines. Kubernetes also lets teams define CPU and memory requests, set limits, consolidate workloads and scale individual services rather than entire servers.

That creates a real opportunity to improve utilization.

But opportunity is not the same thing as savings.

I have seen the opposite problem emerge when clusters become oversized, replicas multiply, resource requests are poorly configured and development environments quietly run all weekend doing absolutely nothing useful.

Then there is the platform itself.

Observability, networking, security, upgrades, backup processes and cluster operations all require engineering effort.

For me, Kubernetes is not inherently cheaper than VMs.

It simply gives me better tools to manage infrastructure efficiently.

The metric I care about is not containers per server. I care about the total cost of reliably delivering the application.

Security Is Where VMs Retain a Natural Advantage

I think this part of the comparison deserves more nuance than Kubernetes secure, VMs secure.

Containers usually share the host operating system kernel. Virtual machines have separate guest operating systems and stronger machine-level isolation through the hypervisor.

That gives VMs a naturally clearer isolation boundary.

Kubernetes can still support very strong enterprise security using RBAC, network policies, workload security controls, secrets, audit logging and admission policies.

The difference is that Kubernetes security is highly configurable.

That flexibility is powerful, but somebody has to configure it correctly.

For ordinary enterprise application isolation, I am comfortable with properly hardened Kubernetes.

For sensitive multi-tenant workloads, applications requiring different kernels or environments where machine-level separation is particularly important, I still see strong reasons for VMs.

Security architecture should follow risk, not whichever platform currently has the better conference stickers.

Stateful Does Not Automatically Mean VM Anymore

Databases used to be one of the easiest arguments against Kubernetes.

That argument has become much weaker.

StatefulSets, persistent storage and Kubernetes Operators have made running stateful applications considerably more practical. Modern cloud-native databases can work extremely well in Kubernetes environments.

Still, I separate capability from suitability.

Kubernetes can orchestrate database workloads, but it does not magically solve database consistency, replication, backup design or recovery.

Those remain database problems.

So I no longer ask whether Kubernetes can run a database.

I ask whether moving that particular database to Kubernetes improves operations, resilience or delivery enough to justify changing a system that might already work perfectly well.

Sometimes the answer is yes.

Sometimes the database would appreciate being left alone.

The Migration Strategy Matters More Than the Platform

When I assess an existing enterprise application, the modernization approach usually tells me more than the technology comparison.

A straightforward rehost changes infrastructure while leaving the application mostly untouched. VMs are naturally suited to that model.

Replatforming goes further. Containerizing an application can improve consistency and deployment automation without requiring a complete redesign.

Refactoring is where Kubernetes becomes much more interesting.

Once an application is redesigned around independently scalable services, automated deployments and distributed resilience, Kubernetes starts solving problems that VM-centric operations handle less elegantly.

This is also why I dislike simplistic TCO comparisons.

Comparing today's functioning VM environment against tomorrow's perfectly optimized Kubernetes platform while ignoring migration and engineering effort makes Kubernetes look suspiciously inexpensive.

Real modernization has a bill.

The Enterprise Future Is Hybrid, Not Kubernetes Versus VMs

I expect serious enterprise infrastructure to become more workload-aware rather than more ideological.

A typical enterprise already operates modern APIs, legacy systems, databases, internal applications, AI workloads and commercial platforms. Expecting all of them to fit one infrastructure model is unrealistic.

I increasingly see Kubernetes and virtualization becoming parts of the same broader platform strategy.

Modern applications can use Kubernetes where automated lifecycle management, portability and scaling create clear advantages. Traditional workloads can remain on VMs where isolation, compatibility and operational stability matter more.

That is why I do not think Kubernetes is the next generation of virtual machines.

I think Kubernetes is the next generation of application operations.

VMs will continue doing an excellent job of abstracting machines. Kubernetes will increasingly abstract modern applications away from those machines.

For me, the mature enterprise architecture is not the one that declares a winner.

It is the one that knows exactly where each model earns its place.

Cloud Firewall As A Service Is The Guardrail I Refuse To Skip

Rakesh Tanwar — Tue, 30 Jun 2026 11:05:56 +0000

I do not treat firewalls like decoration

A firewall is not a badge I place on an architecture diagram to make everyone feel mature.

Cloud Firewall As A Service matters because traffic control matters. Every application has doors. Some should be open. Some should be locked. Some should not exist at all. The firewall is where I begin turning that belief into policy. Without it, cloud security becomes a collection of good intentions and accidental exposure.

FWaaS in India is especially important because businesses are moving faster than their security habits sometimes allow. Teams launch cloud servers, connect databases, integrate partners, expose APIs, and support remote users. That is a lot of movement. A cloud firewall gives me a controlled way to inspect, filter, and manage traffic across that movement. It helps convert cloud speed into cloud discipline.

The old perimeter is not enough anymore

I still respect traditional security thinking, but the cloud changed where the walls live.

In older environments, people talked about the network edge like it was a single gate. Cloud environments are more fluid. Workloads scale, users connect from everywhere, services talk across networks, and applications expose multiple endpoints. A firewall model has to follow that reality. FWaaS gives security teams a flexible way to protect cloud workloads without pretending everything still lives in one neat room.

I like firewall services that fit the cloud rather than fight it. Policies should be manageable. Visibility should be clear. Rules should support business flow without leaving wide open gaps. Security cannot become so annoying that teams route around it. It also cannot be so loose that attackers feel personally welcomed.

FWaaS makes policy easier to carry

Good security depends on clear policy, not heroic memory.

I have seen firewall rules that nobody wanted to touch because each one looked like it had historical significance. That is not security. That is archaeology. Cloud Firewall As A Service helps bring structure to traffic control. It can simplify how teams apply protections across workloads and environments.

With AceCloud FWaaS, the value is in making firewall protection more practical for cloud operations. I want to define who can reach what, which traffic is allowed, which services stay private, and how suspicious patterns are handled. I want those rules to support growth rather than become a dusty corner of infrastructure that everyone fears.

Indian businesses need usable security

Security that only works for specialists in a quiet room is not enough.

Businesses in India are dealing with real cloud security pressure. Customer data, digital payments, remote teams, compliance expectations, and internet facing applications all create risk. At the same time, teams cannot freeze every release waiting for perfect security theater. They need controls that are strong and usable.

That is why FWaaS is valuable. It gives cloud teams a service based model for firewall protection. They can apply traffic controls without building everything manually from scratch. They can keep protection closer to the workloads. They can reduce exposure while still supporting business speed. AceCloud fits this need when it makes firewall capability accessible and operationally sensible.

My view on AceCloud FWaaS

I want firewall services to make security feel like part of the platform, not a punishment for using the cloud.

AceCloud Cloud Firewall As A Service in India is the kind of offering I would want near serious workloads. It supports a more deliberate security posture. It helps teams manage traffic, reduce attack surfaces, and think clearly about access. When combined with VPC hosting, cloud compute, and managed database services, FWaaS becomes part of a stronger cloud architecture.

My opinion is clear. Any business putting important systems in the cloud needs firewall thinking early. Not after the launch. Not after the first audit. Not after someone finds an exposed port and the room becomes very quiet. Early. Deliberate. Managed.

FWaaS is not a magic shield, and I would not pretend otherwise. But it is a practical way to bring policy, visibility and control into cloud networking. That makes it valuable. With AceCloud, Indian businesses can approach cloud security with less guesswork and more structure. That is exactly how I prefer security to feel. Calm, clear, and slightly less likely to ruin dinner.

Managed Database As A Service Is Where I Trade Drama For Calm

Rakesh Tanwar — Mon, 29 Jun 2026 11:06:29 +0000

I stopped romanticizing database firefighting years ago

There was a time when I thought managing every database detail myself was a badge of honor.

Then reality arrived, wearing a pager and a very tired expression. Databases are not impressed by ego. They want backups, patches, tuning, replication, monitoring, access control, storage planning and recovery drills. They want all of that quietly, every day, even when the team is busy launching features or explaining to leadership why a small change took three sprints.

That is why I like Managed Database As A Service. Not because it makes databases magical. It does not. I like DBaaS because it removes the parts that skilled teams should not have to babysit constantly. It lets me focus on schema quality, query behavior, data governance and application design. Those are the places where expertise creates business value. Restarting a failed process at midnight may build character, but so does going to sleep like a normal human.

A managed database is still a serious database

I get mildly dramatic when people confuse managed with casual.

Managed DBaaS does not mean the database stops needing thought. It means the operational foundation is handled with more consistency. Provisioning becomes faster. Backups become predictable. Monitoring becomes visible. Maintenance becomes less dependent on one exhausted person who knows where the scripts are hidden.

I still care deeply about indexes, query plans, connection behavior, storage growth and application patterns. A managed service does not save a badly designed workload from itself forever. It does, however, give me a stronger base. When AceCloud manages the database layer, I can spend my energy on how the data serves the business instead of whether the backup job secretly failed last Tuesday.

The real value is operational calm

My favorite database feature is not flashy, it is calm under pressure.

Every business says it wants uptime. What it often forgets is that uptime is built from boring routines. Backups must run. Replication must be watched. Patches must be planned. Alerts must mean something. Storage must not fill up like a suitcase packed by a toddler. Managed DBaaS brings discipline to those routines.

I have seen teams delay database maintenance because everyone was afraid to touch production. I have seen backup strategies that were basically hope with a folder name. I have seen monitoring dashboards that looked impressive but did not answer the first question during an incident. DBaaS helps replace that drama with repeatable operations. That is not lazy. That is mature.

Why DBaaS makes sense in India now

Indian businesses are digitizing too quickly for fragile database operations to keep up.

Applications are handling more users, more transactions, more integrations, and more data than ever. The database is no longer a quiet box in the corner. It is the heartbeat of customer experience. When it slows, everything feels slow. When it fails, everyone suddenly remembers how important it was.

Managed Database As A Service fits this moment because companies need speed without sacrificing reliability. Teams want to launch quickly, but they also need governance and recovery. They want modern cloud infrastructure, but not a permanent headache attached to it. AceCloud gives that conversation a practical shape. It lets businesses use managed database services while staying focused on outcomes rather than infrastructure chores.

My opinion on doing databases the hard way

I respect deep database skill, but I do not respect unnecessary suffering.

There are cases where a team needs full custom control, and I will defend that when it is real. But many teams are not gaining strategic advantage by manually managing routine database operations. They are just creating more ways for something important to be forgotten. I prefer managed DBaaS when the business needs reliability, scale, and sane operations.

With AceCloud, the idea is not to hide the database from experts. The idea is to give experts a cleaner operating model. I still want visibility. I still want control over the things that matter. I simply do not want every patch, backup, and monitoring task to become a mini project.

My strong view is this. Managed DBaaS is not a shortcut for teams that lack expertise. It is a smart choice for teams that know exactly where their expertise should go. Data deserves serious care. Managed database services help provide that care without turning the team into a 24 hour rescue squad.

Common Mistakes Enterprises Make with Cloud Storage and How to Avoid Them

Rakesh Tanwar — Wed, 24 Dec 2025 10:46:38 +0000

Over and over, I see big enterprises burn money, tank performance, or create compliance nightmares because they treat cloud storage like a magic infinite disk. It isn’t. It’s a toolbox. And if you use a hammer for everything, eventually you’re going to hit your thumb. Here are the most common mistakes I see, and how I’d avoid them if I were rebuilding from scratch.

1. Treating cloud storage like an on-prem SAN
The classic one: “We moved to the cloud, so we provisioned giant network volumes and mounted them everywhere. Done.”

That’s not “cloud,” that’s your old data center with extra steps.

Block storage has its place (databases, certain legacy apps), but:

It doesn’t scale like object storage
It’s usually more expensive at large capacity
It ties data to specific instances and zones

What I do instead
I start with object storage as the default for anything that is:

Shared across teams
Read-heavy
Long-lived

Block storage is reserved for latency-sensitive, tightly coupled workloads. If I catch myself putting “everything” on block storage, that’s my red flag that I’m just re-implementing the old world in the cloud.

2. Keeping everything in the hottest (most expensive) tier
I once reviewed a storage bill for an enterprise where 90%+ of the data hadn’t been touched in over a year—all sitting in premium “hot” storage. Their monthly bill was basically a museum ticket for data nobody visited.

This happens because:

Nobody owns lifecycle policies.
“We’ll clean it up later” quietly becomes “never.”
Teams are afraid of archive tiers because they don’t trust they can get data back.

How to avoid it:

Classify data into hot / warm / cold / archive.
Put automated lifecycle policies on every bucket by default:
- After X days → cool tier
- After Y days → archive or delete
Only exempt datasets where you actively justify why they must stay hot.

My rule: if no one can name a reason a dataset must be hot within 5 seconds, it probably shouldn’t be.

3. Ignoring egress and API costs
Everyone obsesses over “$ per GB per month” and then gets ambushed by:

Cross-region egress
“Chatty” apps making millions of small GET/PUTs
Constant re-downloading of the same objects

I’ve seen GPU training jobs where the storage API bill rivaled the compute bill because the data loader was pulling tiny objects one by one across regions.

How I avoid this?

Co-locate compute and storage in the same region by default.
For high-I/O workloads, shard small files into larger objects (webdataset, tar, parquet, etc.).
Use caching:
- Local NVMe or node-local SSDs as a read-through cache for frequently accessed datasets.
Set up cost dashboards that actually surface:
- Top egress sources
- Top buckets by API requests

If you don’t measure egress and API calls, you’ll be surprised. And cloud surprise is always expensive.

4. No data locality strategy for performance-critical workloads
From the GPU side, this one hurts the most.

I’ve seen enterprises deploy multi-million-dollar GPU clusters, then point them at data sitting:

In another region
In another cloud
On a sad NFS box hidden behind a VPN

Then they wonder why GPU utilization is 40%.

My rule
For performance-sensitive jobs (training, large-scale analytics, latency-sensitive inference):

Data and compute must live as close as physically possible.
For big training workloads:
- Keep canonical data in object storage in the same region.
- Stage active shards onto local NVMe before the job starts.
For critical real-time inference:
- Keep models and key features on local SSD / high-performance block.

If you’re paying for high-end GPUs, it’s almost always cheaper to over-provision fast storage than to let those GPUs idle waiting for bytes.

5. Over-sharing and under-governing buckets
Another common pattern: one giant “data” bucket with:

Broad access
Flat structure
Ad hoc naming
No clear ownership

It works fine until:

Someone deletes a folder they shouldn’t.
An internal tool exposes data it shouldn’t.
Nobody knows who can approve access because “everyone uses that bucket.”

How I handle it?

Design for data domains, not “one bucket to rule them all”: analytics-, ml-, raw-, archive-, etc.
- Assign clear ownership per bucket/domain:
  - Data owner
  - Access policy owner
  - Lifecycle policy owner
Use least-privilege IAM:
- Read-only where possible
- Narrow write permissions
- Strong separation between production and experiment buckets

Security teams love this. So do auditors. But more importantly, it reduces accidents.

6. No versioning, no backups, no restore tests
This is the quiet killer.

I still see critical buckets with:

Versioning turned off
No backup or replication strategy
No tested restore process

Then one day, a bad script runs rm -rf in the wrong prefix, and suddenly everyone discovers that “11 nines of durability” doesn’t mean “undo button.”

My practical approach

Turn on versioning for:
- Any bucket storing production models, configs, or critical reference data.
Have a clear replication / backup story:
- Cross-region replication for “if this region dies, we’re in trouble” datasets.
- Separate “backup projects/accounts” to isolate from accidental deletion.
Actually test restores:
- Pull a random dataset from backup.
- Time how long it takes and what breaks.

If you’ve never practiced a restore, assume it doesn’t work.

7. Letting everyone do “whatever they want” forever
Some chaos is healthy. But I’ve worked with enterprises where every team:

Invents their own folder structure
Chooses random storage classes
Builds slightly different ingestion pipelines

On day one, this feels like “autonomy.” By year two, it’s data hell.

What I recommend?

Create a small set of storage patterns:
- “Analytics dataset pattern”
- “ML training dataset pattern”
- “Archive pattern”
Provide templates and tooling:
- Terraform modules, bucket naming conventions, lifecycle defaults.
Allow deviations—but make them explicit decisions, not accidents.

The goal isn’t central control for its own sake. It’s to avoid having 20 ways to do the same thing, all slightly broken in different ways.

Bringing it together
When I walk into an enterprise as a cloud GPU person, I’ve learned not to start by asking “what GPUs are you using?” I start with:

Where does your data live?
Who owns which buckets?
What are your lifecycle policies?
How often do you move or restore data?

Most “GPU performance issues” I see are really storage design issues in disguise.

If you treat cloud storage as a strategic system (classify data, control access, manage lifecycle, test restores, and care about locality), you’ll get better security, lower bills, and much happier GPUs.

Best Practices for Connecting LLMs to SQL Databases

Rakesh Tanwar — Wed, 24 Dec 2025 10:23:18 +0000

Hooking an LLM straight up to your production SQL database is one of those ideas that sounds cool in a demo and terrifying in a real company.

Done well, you get “ask in English, get SQL + results” and a lot less back-and-forth between data folks and everyone else. Done badly, you get slow queries, wrong numbers in executive decks, or worse, accidental data leaks and write operations you never meant to allow. Enterprise NL2SQL papers and blog posts keep repeating the same warning: accuracy and safety are the main problems, not “can the model write SQL”.

Let’s walk through practical best practices for connecting LLMs to SQL in a way that’s useful, predictable, and not terrifying for your DBAs.

1. Treat the LLM as an untrusted client
First principle: the LLM is not special. It’s just another client that can send weird queries.

So architecture-wise:

Put the LLM behind an API layer, not directly on the database connection string.
Let your backend service:
- Call the LLM.
- Inspect the generated SQL.
- Decide whether to run it, rewrite it, or reject it.

For safety and performance, hit:

A read replica or analytics database, not the OLTP primary.
A separate schema or database user with limited permissions.

Safety checklists for LLM agents all hammer on the same idea: limit tools, limit permissions, and assume the model will eventually do something dumb if you let it.

2. Make the LLM schema-aware (but don’t dump the whole catalog)
Most NL2SQL accuracy issues come from the model not really “knowing” your schema: table names are strange, joins are non-obvious, and column naming is inconsistent. Recent surveys put execution accuracy in the ~60–70% range even for strong models on realistic datasets.

You boost accuracy by feeding the model the right schema context:

Provide:
- Table names and short descriptions
- Column names + types
- Key relationships (PK/FK, common join paths)
Scope the schema:
- Only include tables relevant to the current product area or user.
- For big warehouses, predefine “domains” (sales, support, billing) and only send one at a time.

Tools and guides across vendors (Azure, Oracle, LlamaIndex, etc.) all follow this pattern: index the schema, then give the model a filtered view based on the question.

Too much schema = confusion. Too little schema = wrong joins. Spend time getting this balance right.

3. Use a two-step reasoning pattern, not “prompt → SQL → run”
Direct “question in, SQL out, execute immediately” is fragile. Better to split it:

Interpret the request
- Have the model restate the question in structured form:
  - Intent (report vs lookup vs debug)
  - Entities (customer, product, region, time range)
  - Output shape (single value, table, time series)
Generate SQL from that plan
- Ask the model to produce SQL and a short explanation of the join logic and filters.

Chain-of-thought style prompting (even if you don’t show the thoughts to the user) consistently improves SQL generation quality in studies and production write-ups.

Implementation tip:

Parse only the SQL part (e.g., fenced in a code block).
Ignore anything else when executing.

That gives you something to log and debug when a query misbehaves.

4. Lock down what SQL the model is allowed to run
Don’t rely on “please don’t write DELETE statements” in the prompt. Enforce it.

Concrete rules that work well:

Read-only DB user
- Only SELECT allowed.
- No INSERT/UPDATE/DELETE/MERGE, no DDL.
Single-statement rule
- Reject queries with multiple statements or suspicious delimiters.
Row and time limits
- Always add LIMIT and sane timeouts.
- For dashboards, page the results.
Column allow-listing
- Exclude PII or sensitive columns at the schema layer, or expose only safe views.

Some teams go one step further and allow the LLM to call only stored procedures instead of emitting free-form SQL. That trades flexibility for strong control: the model picks a stored proc and fills in parameters, but can’t touch arbitrary tables.

Whatever you choose, implement checks in code before execution, not just in the prompt.

5. Validate and sandbox queries before hitting real data
Even with a read-only user, ugly queries can still hurt performance or return nonsense.

Good guardrails:

Static checks
- Parse the SQL (e.g., with your language’s SQL parser) and inspect the AST.
- Reject:
  - Cross-database references
  - Dangerous functions
  - Huge cartesian joins
Dry run or EXPLAIN
- Run EXPLAIN first and reject queries with insane cost estimates or full table scans on huge tables.
Result sanity checks
- Enforce row count caps.
- If the result is empty or obviously off, you can ask the model to debug/adjust the SQL instead of returning junk.

Research on constrained NL2SQL and runtime enforcement basically boils down to this: let the model propose queries, but use hard-coded constraints to keep execution safe.

For sensitive environments, consider running first against masked or synthetic data to test prompts and behavior.

6. Put a human in the loop where the blast radius is high
Not every query needs approval. But some really should.

Patterns that work:

For ad-hoc analytics or internal reporting, you can usually auto-run reads with good guardrails.
For actions that:
- Affect pricing, payouts, or compliance, or
- Touch very sensitive tables
…show the SQL and a plain-English summary to a human for approval first.

Safety guides for LLM agents explicitly recommend human review for any high-impact actions like editing databases; querying sensitive data can fit the same pattern depending on your risk profile.

Make it easy for the reviewer: include the original question, the generated SQL, and a quick explanation of what the query does.

7. Log everything and measure accuracy over time
NL2SQL is not “solved”, especially once you move beyond academic benchmarks into messy enterprise schemas.

Treat your LLM–SQL layer as a product:

Log:
- User question
- Schema context you passed in
- Generated SQL
- Execution plan and runtime
- Result shape (row count, columns)
Sample and label:
- Regularly review a subset of interactions.
- Mark which SQL queries:
  - Ran successfully
  - Returned correct answers
  - Needed manual fixes
Track:
- Execution accuracy (did the SQL run).
- Answer accuracy (was it the right question / result).
- Latency and cost.

This gives you a feedback loop when you change models, prompts, or schema, and lets you catch regressions early.

8. Start narrow, then widen the blast radius
The safest path is to begin with a tight use case and expand.

A nice rollout order:

One domain, one schema
- e.g., just analytics on a reporting replica of your billing DB.
Internal users only
- Data/BI teams who can spot nonsense quickly.
Gradual schema expansion
- Add more tables and domains once you trust the behavior.
Broader audiences and more powerful queries
- Only after logs and metrics show stable, predictable behavior.

You’ll learn a lot about your own data quality, naming, and join structure along the way, which often leads to better views and marts even outside the LLM use case.

Wrapping up
Connecting LLMs to SQL databases isn’t just about getting fancy demos where someone types “show me revenue by region” and a pretty chart appears. The hard part is everything around that moment: scoping schema, locking down permissions, validating what runs, and tracking whether answers are actually right.

If you treat the LLM as an untrusted client, keep it schema-aware but constrained, add hard checks around the SQL it emits, and watch behavior with real metrics, you can give people a natural-language window into your data without giving your DBA a heart attack.

Why GPUs Are Critical for Medical Image Processing

Rakesh Tanwar — Mon, 22 Dec 2025 10:45:06 +0000

If you’ve ever worked with medical imaging data, you know it doesn’t behave like “normal images.” A CT study isn’t one picture. It’s a stack of slices, sometimes hundreds of them. MRI can add multiple sequences. Ultrasound can be a stream. Then you layer on reconstruction, denoising, segmentation, registration, and sometimes deep learning inference on top. That’s why GPUs are critical for medical image processing. Not because GPUs are trendy, but because the math and the data volume line up almost perfectly with what GPUs do well.

This isn’t medical advice or a claim about clinical outcomes. It’s just the compute reality: if you want faster turnaround and fewer pipeline bottlenecks, GPUs usually end up in the middle of the system.

Medical imaging is a data-heavy problem, not just an “image” problem
Once you treat it like 3D data plus workflow pressure, the GPU case makes more sense.

A typical computer vision workflow might deal with 224 by 224 images. Medical imaging often deals with full volumes, and sometimes time series on top. Every step you do, filtering, resampling, masking, is repeated across millions of voxels.
That size has a knock-on effect: it increases memory traffic, increases compute, and makes “do it on CPU later” feel like a slow leak that turns into a backlog.

The core reason GPUs win: parallel math and high memory bandwidth
Medical image processing is full of repeated operations, and GPUs are built for that kind of repetition.

A lot of medical imaging workloads boil down to “apply the same operation across a large grid,” whether that’s a convolution, interpolation, thresholding, or a more complex kernel. GPUs can run thousands of threads in parallel, which maps nicely to voxel-wise and pixel-wise work.

The other side of it is memory. Moving and touching large volumes costs time. GPUs are designed to push a lot of data through math units quickly, and many imaging steps are limited by memory bandwidth as much as raw compute.

Reconstruction is where GPUs earn their keep
In several modalities, you’re not loading an image, you’re building it from raw measurements.

MRI and ultrasound reconstruction leans hard on FFT math
MRI reconstruction commonly uses the Fast Fourier Transform as part of turning acquired signal data into an image. NVIDIA’s GPU Gems includes a chapter explicitly showing GPU-based FFT work for MRI and ultrasonic imaging reconstruction.

That matters because FFT work is highly parallel and can be a big chunk of total reconstruction time. Research literature also calls out FFT acceleration as a key theme for speeding advanced MRI reconstruction algorithms.

Iterative CT reconstruction is compute-hungry
Iterative reconstruction methods can improve image quality, but they’re heavier than simpler analytic methods. There are papers focused on accelerating iterative CT reconstruction on GPUs, including work exploring GPU features like Tensor Cores for speeding iterative CT reconstruction.

The takeaway isn’t “every CT pipeline uses this.” It’s that reconstruction can easily become the dominant compute cost, and it’s a very GPU-friendly cost.

AI in medical imaging is GPU-first by default
Once you start training or running 3D models, CPUs stop being the default option.

If you’re doing segmentation, detection, triage, or classification, you’re usually pushing big tensor ops over 2D stacks or full 3D volumes. That’s why most practical medical imaging AI stacks assume GPUs, especially when you move from 2D to 3D segmentation.

A good example is MONAI, a PyTorch-based, open-source toolkit built for healthcare imaging AI. It’s part of the PyTorch ecosystem and is designed around deep learning workflows for medical imaging.

One practical detail people miss: GPUs help twice here. First, for training. Second, for inference throughput when you need to run models over many studies, many slices, or a live queue. Even if a single inference is “fast enough,” queues are where latency becomes a real workflow problem.

Don’t ignore the boring bottlenecks: decode and data movement
A fast GPU model won’t help if your pipeline can’t feed it.
DICOM workflows often involve compression and decoding. JPEG 2000 shows up in medical imaging and digital pathology, and decode can become a real bottleneck when you scale. NVIDIA’s nvJPEG2000 library is specifically aimed at accelerating JPEG 2000 decoding and encoding on NVIDIA GPUs, with parts of the decode offloaded to the GPU.

NVIDIA has also written about GPU-accelerated medical image decoding using nvJPEG2000 in the context of DICOM images.
This is where a lot of teams get surprised. They upgrade the model, see no speedup, and the reason is simple: decode and transfers are stalling everything.

What to look for in a GPU setup for medical imaging
You don’t need the “biggest GPU,” but you do need the right shape for your workloads.

First, VRAM. 3D volumes and 3D models eat memory fast. If you’re doing full-volume inference or training, VRAM is often the first constraint you hit.

Second, predictable throughput. For imaging pipelines, it’s rarely one job. It’s many studies, batching, retries, and a queue that’s always there. Stable performance is more useful than peak benchmarks.

Third, plan for where the data lives. If your GPU is fast but your storage or network is slow, you’ll see stutters. Medical imaging workloads punish slow I/O.

Summary
GPUs matter in medical image processing because the workload is a perfect storm: large 3D data, repeated math, heavy reconstruction steps, and deep learning that lives on tensor ops. Reconstruction benefits from GPU-friendly computation like FFTs in MRI and ultrasound, and iterative approaches in CT can be heavy enough that GPUs become the only practical way to keep turnaround reasonable.

And the less glamorous part is just as real: decode and data movement can bottleneck the whole system, and GPU-accelerated decoding libraries exist for a reason.