Very legitimate concern and one I've been thinking about a lot. Honestly, I think the best way to address this is to just go open source, which I'm totally open to. I think once I've validated the idea a bit and know it's something people are interested in, I'll focus on this issue and come up with a solution (whether it's open sourcing or something else)

Going open source will not solve your problems. The issue is that youre asking customers to open database access to you/your company. The reason why the method youve chosen isnt already out there is because of all the implications it has.

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.

Definitely taking all the security measures I can, but you're right, things can go wrong. I do encourage (and would like to enforce) that db credentials provided should have very limited read access to only the tables/columns that the user wants to query.

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.

You dont need to go open source to allow self hosting, and, youll likely lose money that way. Its entirely possible to allow self hosting without being open source. Plenty of other projects do it.

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.

You realize that the sending is done by Amazon SES right?

I did not.

At that point id just configure SES outright and not even use this solution. Most other services use direct mailing from their own servers

I'm not a security expert, but at the very least if I were you make your docs very good for people who dont want to wade through 1000 different documentation to find how to very simply create a read-only user with access to specific table + columns. Or better yet even, how to create a read only view with ONLY the email/name and not any other PII, and then give access to that.

A self hosted AMI/container - with a config UX. Simple solve.

I was super excited when this popped up because I'm looking into solutions for this problem right now. I was, however, surprised to see it wasn't self-hosted or open source.

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.

Agreed. This makes me incredibly uncomfortable. I'd rather a simple SDK that pushes the contact details to their API.

Another issue is that the data needed by this application is going to be sensitive - email addresses, names, etc. Many applications will encrypt these values with application logic. So a database function will need to perform it. The encryption key is going to be need to written into the query in this app if that works, adding more surface area to where that key lives. That's also assuming the simple use case of a single key, not per tenant, or roating, etc.

Yeah what’s the hesitation for having an API?

I think even more interesting is that they chose to forgo the rather robust and easy to use API offered by Mailchimp in the first place.

Mailchimp have already exposed customer user data. Controlling the integration in this way is likely more secure, not less.