You can and should abstract out your data layer. However, before you arbitrarily decide that your aim is to support multiple databases you need to realise that:
- All databases have their quirks and behave in different ways, so even if you use an ORM (the entity framework is OK, but I'm not convinced about how good it is for large data volumes) you need to be aware that it might not work identically for all databases (distributed transactions may or may not be supported for example). Given this you increase your development cost, possibly considerably, if you want to provide a consistent experience across all databases.
- Even if you ORM is Awesome and does everything identically in every database, you still need to run all of your acceptance tests in each database environment to confirm this which definitely increases your QA costs.
Now you are writing a .NET website, by the sound of it for the consumer market, so it will be hosted on a box somewhere like Godaddy with access to a SQL Server database as part of the package.
Given that what is the expected return on investment from supporting any database other than SQL Server?
I would say that only if you think this figure is positive and in proportion with your other development costs should you consider supporting more than one database, and then only support other databases once your product is established and stable with a SQL Server back end and there is a definite demand from your customers.