You better have one hell of a security team to ensure youre locked down tighter than a ducks ass. Look at how many data breaches there have been, even in the past year.
The solution is to either make an SDK or API as already suggested by others, and giving customers endpoints to manage their lists.
Having said that, it's totally understandable that some orgs won't want do open up their db. The idea with going open source would be that they can host the platform in their VPC so that their data is never leaving the premises.
Not against having an SDK or API at all, but I would need to think about would work because the whole syncing issue is one that I'm focused on addressing here.
That being said, self hosting doesnt solve all issues.
You, and whoever uses this product, will need MANY IPs because of blacklisting and throttling limits applied almost worldwide to all mail servers. Theres a reason why the marketing spam hosts have their own /24 or /25 and have 80% of them cycling through usage as a mail sender.
Im not knocking your want to have something better than MailChimp and the like, but i feel like you didnt really dig into the real underlying tech and security before you went to work on this.
At that point id just configure SES outright and not even use this solution. Most other services use direct mailing from their own servers
As others have mentioned, there are security issues here that would be a non-starter for me. Even just having to open a database to the open internet for an external service to connect to is too much, even if I trusted that service completely.
Self-hosted fixes these issues since outbound traffic can be locked down so only connections to SES are allowed, and no databases have to be exposed to the internet.
However, many people will also not want more than 1 service talking directly to a database for a few reasons:
1. Databases are often a single point of failure. A bad query can take down a whole service. Allowing queries that don't pass code review can be dangerous here, even if it's locked down to be read-only. This can be mitigated by talking to replica databases, but that's more setup.
2. Migrations on data that is accessed directly from multiple services becomes harder. Many server frameworks handle data migrations, and they assume ownership of the data. These frameworks cannot account for other services and cannot make sure the queries will continue to work. This is less of an issue if the query is a one-off though.
3. Having multiple services talk directly to a database pushes all the security, data validation and processing to the database. Many developers (myself included) prefer to keep database configuration as simple as possible since they are already complex.
Anyway, sorry for the long post, but I thought my experience might be useful in developing this! Generally, I'd love to see a simple, self-hosted MailChimp. Especially one where I could keep all the configuration in version control.