Let's face it, there is a wide variety of skill out there. If you spend any time monitoring StackOverflow, MSDN forums, Ask SQL Server Central or twitter's #sqlhelp hash tag, you'll be very well aware that there are people out there barely managing their database environments - people that some of us wouldn't let within a mile of our own data centers. But a lot of these people are not trying to build the next facebook or amazon - they're just trying to keep their small business running, and don't necessarily need perfection.
One of the "live by the sword, die by the sword" problems with SQL Server is that it has become so easy to manage. (I remember one of the mantras of SQL Server 7.0 was to make it so self-tuning that a DBA wouldn't be needed. That's not quite how it turned out, but a lot of systems are certainly less hands-on than they were in the 6.5 days.) Because of this, in probably a good 80-90% of cases, a business can get by with minimal or no DBA expertise. While some of the things that people will set up instinctively (e.g. maintenance plans) will not be the most efficient things in the world, they're also not going to be bad enough to cause the business any grief - they're just not trying to squeeze so much performance out of the system that these minor inadequacies are really going to cause them any grief.
Does that mean you should stop learning, and ignore great blog posts on backups, compression, security, and other important aspects of SQL Server? Of course not. The challenge is to know when you will need those skills to be present. At the beginning, for most start-ups, I wouldn't suggest that a rockstar DBA is priority #1. But as your application becomes the next big thing, there will come a time when boot-strapping it just isn't going to cut it anymore. If you don't have a database person on staff or retainer periodically looking at your stuff, you can end up in a really bad situation.
A lot of the things that you started on an "expertise budget," we'll call it, can be fixed later on; but some things will be more challenging. Storage, for example, is important... but as long as you can afford maintenance windows or other scheduled downtime, moving from DAS to SAN is something you can do when it's required (and when the budget is justified). Similarly, scaling up to larger machines, or adding memory, are things that are relatively easy to do and don't necessarily require a DBA (except maybe in downtime planning or data migration).
On the other hand, choosing whether to use IDENTITY or application-generated GUIDs as a primary key is something you should put more thought into up front, because re-engineering both the schema and the application(s) is not something you can pull off during a Saturday afternoon maintenance window. Nor is being prepared for scale in general... you don't want to get caught with your pants down, thinking 10GB drives were big enough, and you run out of disk space on day 2. You probably don't need a high-end DBA for ballpark capacity planning (take your best guess and double it), or to figure out efficient ways to replicate and distribute data (I wrote about this a little bit last year).
Now, please don't take this the wrong way. I am not saying that DBAs are useless, nor am I suggesting that you *should* avoid a DBA at all costs. I just think that, in some scenarios, you can live without a DBA - for a little while. Not all applications need to be bleeding edge, and many will never grow beyond very meager needs (I wonder how many of today's apps could feasibly run on Express?). In fact many of these apps are going to start moving to the cloud, where even the rockstar DBAs out there won't have much control over storage, availability, redundancy, etc. So some DBA skills are, at least to some degree, being deprecated right out from under us. Maybe you're not currently in a position where you need to worry about this, but how confident are you that this will always be the case?
Thanks to Paul Randal (blog | twitter) for hosting and coming up with this month's T-SQL Tuesday topic!