Thank you for this feedback. I do believe actually retaining the data in a searchable format would require significant resources. I note Comodo wrote their own PostgreSQL extension for this purpose[0], something I&#x27;d imagine would not be done lightly.<p>However, I&#x27;ve found it surprisingly efficient for the type of service I&#x27;m running. It&#x27;s currently running on a single Linode instance with 2G RAM. I&#x27;ve got load averages on the box of 0.05, so I think it&#x27;s easily handling things. I have various parts of the service running in spawned threads, and I&#x27;ve tested that I can configure the timing to be more aggressive than it currently is it needed.<p>In terms of keeping up, I had the service shutdown for over 48 hours days whilst debugging a frustrating race condition in the PostgreSQL driver[1] and it managed to catch up in a few hours.<p>What has held up online registration is the place where load is in fact a significant issue - in testing, I set myself up monitoring *.cloudflaressl.com, which is known to rotate regularly. I nearly hit the Amazon SES free tier limit and gave myself an Office 365 inbox I can&#x27;t open without crashing IE. Obviously I need to ensure users can&#x27;t do the same.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;crtsh&#x2F;libx509pq" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;crtsh&#x2F;libx509pq</a>
[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;epgsql&#x2F;epgsql&#x2F;issues&#x2F;80" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;epgsql&#x2F;epgsql&#x2F;issues&#x2F;80</a>